Re[2]: Java vs C# vs C++ - Философия программирования

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

_>>>·>Т.е. ты даже в двух строчках кода забыл "x=nullptr"... А в случае более-менее сложного кода, да ещё и многопоточного — только в путь.
_>>>Ну так у меня же мало практики в написание заведомо некорректного кода. Я вообще сам delete раз год вижу, даже с корректным кодом. А тут такое... )))
_>·>Ты написал его типично. Чаще так оно и происходит. Время жизни в одном месте, удаление в другом месте, добавленное в другое время, другим девом в другом потоке.

_>Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг

_>

_>{
_>    auto x=make_unique<T>();
doSomethingProbablyInAnotherThread(*x);// а если так?
_>    //...
_>} //в этой точке вызывается delete (сам!)
_>// а здесь уже не добраться до указателя, чтобы продемонстрировать обсуждаемое поведение
_>

_> (в отличие от Жабки, где это без проблем):
И чем это отличается от Жабки-то?

{
   T x = new T();
doSomethingProbablyInAnotherThread(x);
   //...
}//в этой точке x становится доступен для gc (сам!), но только если ссылка никуда в другой контекст не ускользнула.
// и чё?

_>>>В своих, ушедших в продакшен, — не видел. )
_>·>А сколько девов принимало участие? Сколько человеколет? Если меньше 5 девов, менее сотни человеколет, то это мелкие проекты... Их хоть на ассемблере пиши, не принципиально.
_>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
Дело не в delete, а в &-ссылках или *-указателях.

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

_>·>Говорю же — два режима оптимальны. Второй режим — объекты создаются и уничтожаются редко. Редко меняется граф объектов в памяти. (т.е. топология графа не меняется, но данные внутри объектов меняться могут).
_>·>Неоптимальный режим — создали кучу объектов, помариновали их какое-то время и потом грохаем.
_>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.
Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!

_>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).
Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.

_>>>Соответственно, чтобы догнать C++ на задачах реалтайма, высокой нагрузки и т.п. (в остальных областях тоже медленно, но всем просто пофиг) в Java переходят от дефолтного режима на некое извращение с рукопашными буферами и т.п. ужасами для эмуляции стандартных техник C++.
_>·>Собственно и в плюсах ты переходишь от комфортного by-value/on stack к хитрым аллокаторам, жонглированию различными типами указателей, повышая риск что-то поломать или потерять.
_>Ещё раз повторяю: на C++ я перехожу к такому режиму только на очень узком спектре задач, требующих постоянное создания/удаления мелких объектов. Обычно такое наблюдается при написание каких-нибудь компиляторов, интерпретаторов и т.п. На большинстве задач такого нет даже близко. И уж тем более не в области LL, где все выделения памяти рекомендуется сделать вне главного цикла.
Так ведь есть ещё неглавные циклы...

_>>>Т.е. главный нюанс в том, что хотя в обоих языках есть области, требующие неких нестандартных для языка подходов, эти области совершенно разные у данных языков. И размеры этих областей тоже принципиально разные.
_>·>Собственно в LL-системе "плохая" часть очень маленькая. Только из малой области кода выжимаются все соки, а остальное пишется как обычно, с комфортом GC.
_>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))
Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.

_>>>Абсолютно не такая же. Напомню, что мы здесь обсуждали возможности JIT выбрать расположение и типы данных (куча/стек, ссылка/значение и т.д.) наиболее оптимальным способом. И в отличие от качества генерирования ассемблерного кода оптимизаторами C++, тут ситуация даже не приблизилась к идеалу. И я сомневаюсь что приблизится когда-нибудь, т.к. тут задача намного сложнее.
_>·>Принципиально — для JIT оптимизаций доступно гораздо больше информации, т.к. оно работает во время испонения. И оптимизация происходит именно в соответствии с реальной нагрузкой. Есть, конечно Profile Guided Optimisation, но она, насколько я знаю, представляет в основном академиеческий интерес.
_>Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.
А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.

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

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

_>>>Огромный зоопарк COM компонентов и так присутствует на любой винде, потому что это одна из базовых технологий и на ней подстроено очень много подсистем.
S>>Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.

_>Т.е. DirectX тоже перепишем под .net и будем запускать через обёртку? )))
Если надо то нет проблем http://habrahabr.ru/post/142025/

_>>>>>Управляемые языки — это слишком широкий термин, надо говорить конкретнее. А то ведь к ним относятся и Python с JS. )))
S>>>>Я как раз имел ввиду все манагед языки. Ибо есть ведь и манагед С++.
_>>>В таком случае ты наврал, причём ещё и от моего имени. Т.к. я никогда не говорил что "C++ наше всё", подразумевая его как замену и Python'у, JS, и т.п.)
S>>Но ты говоршь, что C# то отстой и что С++ в связке с Питоном это ваше все.

_>Я как раз говорил, что частенько использую Питон сам по себе. Да и JS приходится иногда.
Да уж куда без него. А я вот предпочитаю TS

S>>А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.

_>А тут кто-то с этим спорит? )
Пока вы все говорите, то что делается на C# легко реализуется на C# и с лучшей скоростью. Я привожу примеры, что это не так.

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

EP>>А вообще там оппонент непонятно зачем начал показывать готовый Complex в C#, хотя пример был совершенно не про это. В ответ я и показал что есть из коробки в C++

S>Речь в моём сообщении шла о выделенных жирным параметрах конструктора. Пользовательские суффиксы (уж извините, не знаю как они официально называются) из всех виденных примеров только тут их использование хоть чем-то оправданно.

Выше был пример про единицы измерения + dimensional analysis.

EP>>Кто? Я как раз говорю что язык в том числе и не гибкий.
S>Вы пытаетесь приводя удобные вам примеры доказать что для удобных вам задач язык не подходит.

Я уже в этой теме говорил, что использую и C++ и Python, и даже C#. И да, для задач выбираю тот язык который более удобен

S>Особого смысла спорить с этим нет, однако в прошлом обсуждении ответа, к примеру, на не очень удобный вопрос по рефлексии в языке как-то не последовало.

Это демагогия. Вообще-то я сразу сказал что это недостаток:

S>>Нету у вас рефлекшина.

EP>Нету, это недостаток, сейчас кое-как эмулируется. При этом reflection не обязательно должен быть runtime — он может быть compile-time, и такой скорей всего и введут.

Какой ещё ответ должен был последовать?

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

I>>Можно проще — .Net рулит для бизнеса.
I>>C++ — всего лишь для некоторой части инфраструктуры.

_>Ну т.е. всякие там гуглы, яндексы или вообще варгейминги — это не бизнесы? )))

Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.

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

EP>Выше был пример про единицы измерения
Как раз бессмысленный синтаксический сахар. Фактически вместо KG(5) пишем 5kg — нереальный выигрыш.

EP>+ dimensional analysis.
Посмотрю чуть позже.

S>>Особого смысла спорить с этим нет, однако в прошлом обсуждении ответа, к примеру, на не очень удобный вопрос по рефлексии в языке как-то не последовало.

EP>Это демагогия. Вообще-то я сразу сказал что это недостаток:
Да неужели? Вот память-то меня подводит:

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

А вот раскрыть подробности внешней утилиты — этого я уже не дождался.

EP>Какой ещё ответ должен был последовать?
Кровавые подробности того как:

И эта добавленная рефлексия, позволит мне, к примеру, загрузить внешний модуль (чужой внешний модуль) в рантайме, пройтись по его классам, выбрать нужные мне, создать их (instantiate) и заглянуть во внутрь рефлексией?

Реализуются внешней утилитой.

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

EP>>Зачем если есть обычный Python?
S>>>немерле.
EP>>Речь-то про C# vs Python. Nemerle — это другой разговор.
S> А то, что если мне вдруг не будет хватать C# я легко могу сделать сборку на любом нетовском языке

А я вообще возьму любой язык

S>>>Ну дык сделай на питоне эту задачу. Все ведь элементарно.

EP>>Интерпретатор уже готовый, тратить время на оборачивание его в какое-то API, привязанное к одной конкретной платформе — мне не интересно.
S> Ну вот начинается. А у меня все сделане для любой нетовской сборке и написано за 15 минут.

Вот практически готовый пример.

EP>>Это вряд ли, у меня нет цели всех переманить на C++. И как уже говорил, я сам его не везде использую.
EP>>Я лишь показываю что о C++ много мифов, люди строят какие-то предположения на основе каких-то старых баек, и на основе этих неверных предположений принимают какие-то неверные решения, и более того — распространяют эти мифы дальше. Вот это вот всё нужно купировать.
S> Надо признавать факты того,

А я не отрицал. Я тебе в первом же ответе сказал что иногда сам использую C#, но ты это продолжаешь упорно игнорировать, и спорить с какими-то воображаемыми тезисами.

S>что определенные вещи легко делаются на Net? чего нет в ваших любимых нативных языках.

Есть некоторые вещи которые проще на .NET.

S> А так упорствуй дальше и считай что C++ в связке с Питоном это верх совершенства.

Это откровенное и наглое враньё

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

EP>>Выше был пример про единицы измерения
S>Как раз бессмысленный синтаксический сахар. Фактически вместо KG(5) пишем 5kg — нереальный выигрыш.

Один из мотивирующих примеров. Другие use-case'ы: бинарные литералы, литералы для больших чисел.

S>>>Особого смысла спорить с этим нет, однако в прошлом обсуждении ответа, к примеру, на не очень удобный вопрос по рефлексии в языке как-то не последовало.
EP>>Это демагогия. Вообще-то я сразу сказал что это недостаток:
S>Да неужели? Вот память-то меня подводит:
S>

Сейчас же это реализуется через макросы, причём получается даже чище чем в языках с передовым мета-программированием.

В этой цитате была конкретная ссылка.

S>

В целом же рефлексию добавить внешней утилитой намного проще чем восполнить отсутствующее метапрограммирование.

S>А вот раскрыть подробности внешней утилиты — этого я уже не дождался.

Там дальше же подробности и описываются:

EP>>>В целом же рефлексию добавить внешней утилитой намного проще чем восполнить отсутствующее метапрограммирование.
EP>Генерация классов по схеме это элементарная операция, часто кстати требуется генерировать код для разных языков, для interoperability, а ещё и документацию.

То есть генерируй классы по схеме чем угодно, хоть тем же Python'ом. В одном из проектов у меня так и происходит, причём там генерируется не только C++ код — то есть генерировать всё равно пришлось бы.

Другой вариант например взять выхлоп от SWIG:

SWIG can also export its parse tree in the form of XML and Lisp s-expressions

EP>>Какой ещё ответ должен был последовать?
S>Кровавые подробности того как:
S>

И эта добавленная рефлексия, позволит мне, к примеру, загрузить внешний модуль (чужой внешний модуль) в рантайме, пройтись по его классам, выбрать нужные мне, создать их (instantiate) и заглянуть во внутрь рефлексией?

S>Реализуются внешней утилитой.

Я вполне явно говорил про compile-time reflection
Если автор этого стороннего модуля применит её — то из неё легко автоматически получить runtime reflection. Если есть заголовки — то это можно сделать на своей стороне. Если же нет заголовков — тогда вообще о чём идёт речь? О неизвестно откуда полученных бинарниках?

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

_>>Это типично для C. На C++ такой код вообще не встречается. Просто на нормальном для C++ коде было бы невозможно продемонстрировать описываемый тобой баг
_>> (в отличие от Жабки, где это без проблем):
·>И чем это отличается от Жабки-то?

Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.

_>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
·>Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
·>Дело не в delete, а в &-ссылках или *-указателях.

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

— использование контейнеров stl (если конечно не требуется чего-то специфического)
— следование какой-то известной архитектуре организации многопоточности (например мне нравится модель акторов).

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

_>>"Второй режим" вообще никому не интересен, т.к. для редко создаваемых объектов вопрос быстродействия подсистемы памяти вообще не стоит, в любом языке.
·>Различного вида буферы, кеши, пулы — это оно. Они никому не интересны??!

Не интересно время их выделения/уничтожения, потому как сам же говоришь, что это происходит редко.

_>>Что касается "первого режима", то оптимальный он только внутри мира Java, т.к. полностью проигрывает дефолтному режиму работы C++ (переменные на стеке и т.д.).
·>Не только. Скажем, создать объект в треде А, передать его тредам Б, В, Г, и, иногда Д, затем быстренько обработать и удалить. Соорудить такое в С++ — можно только очень осторожно.

Не очень понятно. Эти самые потоки "Б, В, Г, и, иногда Д" должны получить изначальную версию объекта, обработанную версию объекта, или обе? )

_>>Да, всё верно. Ну а на C++ все части пишутся с комфортом. )))
·>Если уж по правде говорить, то С++ синтаксис на порядок сложнее java (надеюсь, не будешь спорить?). А поэтому да, с таким же комфортом. Однако этот комфорт ниже типичного в Яве. Особенно при наличии IDE.

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

_>>Я говорю не про теорию, а про практику. В теории компиляторы могли создавать отличный ассемблерный код и 30 лет назад — ничего этому не мешало. Однако на практике они достигли уровня, сравнимого с человеком, только лет 5-10 назад. Так вот в области автоматической оптимизации типов и т.п. на практике нет пока почти ничего реально работающего. Может лет 10-20 и появится что-то существенное, но пока такого нет.
·>А вот теперь представь, что этим компиляторам дают не только исходный код, но и статистику реального выполнения программы с реальными данными.

Такое тоже уже давным давно используется в мире C++ https://blog.mozilla.org/tglek/2010/04/12/squeezing-every-last-bit-of-performance-out-of-the-linux-toolchain/ и иногда действительно даёт неплохие результаты. Но тут дело совершенно не в этом. Вопрос не в инструментах, а в задаче. Проблема выбора оптимальные контейнеров и алгоритмов не идёт ни в какое сравнение с проблемой оптимизации ассемблерного кода под современные процессоры. И то с последней сколько лет возились...

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

S>>>Так зачем этот зоопарк если можно без него? Проще использовать оди Com компонент который загружает сборки.
_>>Т.е. DirectX тоже перепишем под .net и будем запускать через обёртку? )))
S> Если надо то нет проблем http://habrahabr.ru/post/142025/

S>>>А я говорю, что у каждого языка есть своя ниша. Свои достоинства и недостатки.
_>>А тут кто-то с этим спорит? )
S> Пока вы все говорите, то что делается на C# легко реализуется на C# и с лучшей скоростью. Я привожу примеры, что это не так.

Да, большая часть задач, решаемых на C#, может быть решена на C++ проще и с лучше скоростью. Но это не значит, что у C# нет своей ниши, потому что предыдущее утверждение делалось в расчёте на экспертные знания в каждом языке. Если же брать специалистов более низкого уровня, то ситуация становится совсем другой. Собственно на этом Java/C# и живут.

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

I>>>Можно проще — .Net рулит для бизнеса.
I>>>C++ — всего лишь для некоторой части инфраструктуры.
_>>Ну т.е. всякие там гуглы, яндексы или вообще варгейминги — это не бизнесы? )))
I>Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.

Что-то понятие "основной продукт компании" не укладывается ни в понятие "инфраструктура", ни в "бизнес-специфику" (для данных компаний)... )

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

I>>Бизнесы. Инфраструктура в них пишется на плюсах. Бизнес-специфика — в основном на менеджед решениях. Драйвер — инфраструктура. База данных — инфраструктура. Как то так.

_>Что-то понятие "основной продукт компании" не укладывается ни в понятие "инфраструктура", ни в "бизнес-специфику" (для данных компаний)... )

Именно. Потому как слово продукт слишком общее, потому и надо уточнять
Пример 1. Основной продукт — инфраструктура.
Пример 2. Основной продукт — бизнес-решения.
Пример 3. Основной продукт — сыр 'Беловежский'.

Бизнес-решения == инструменты для конкретного бизнеса, как правило автоматизация.
Вопрос — чего ты драйвером в видеокарте автоматизируешь ?

Есть продукты, которые ни инфраструктура, ни бизнес-решения. Например игрушки.
И вот вопрос — что пишут в варгейминге на с++, а что на менеджед ?
Все вопросы связаные с автоматизацией бизнеса самого варгейминга пишутся на менеджед решениях. Ну например биллинг тот же.
Клиентская часть,все что связано с юзером — менеджед, например флеш. Низкоуровневая инфраструктура — С++.
Серверная часть, внимание — похожий расклад.

Что касается яндекса и гугла — все примерно так же. Драйвера, числодробилки, и прочая инфраструктура — С++. Остальное Джава, Питон и тд.

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

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

EP>>>Зачем если есть обычный Python?
S>>>>немерле.
EP>>>Речь-то про C# vs Python. Nemerle — это другой разговор.
S>> А то, что если мне вдруг не будет хватать C# я легко могу сделать сборку на любом нетовском языке

EP>А я вообще возьму любой язык

S>>>>Ну дык сделай на питоне эту задачу. Все ведь элементарно.

EP>>>Интерпретатор уже готовый, тратить время на оборачивание его в какое-то API, привязанное к одной конкретной платформе — мне не интересно.
S>> Ну вот начинается. А у меня все сделане для любой нетовской сборке и написано за 15 минут.

EP>Вот практически готовый пример.

Воо уже более интересно. У питона есть информация о типе. Только несколько замечаний
Есть ref и out параметры которые тоже нужно оборачивать как и результат функции.
Теперь осталось показать подгрузку питоновских сборок и 1С ники будут благодарны.
Еще бы и реализацию ITypeInfo, но это уже незачем.

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

I>>>>>Джава в роли догоняющего.
I>>>·>Примерно как С++ догоняет Кобол.
I>>>Кобол в HFT ? Пудозреваю, исключительно за счет С++.
I>·>В finance.
I>HFT это уже не финансы ?
финансы это не только HFT.

I>>>Сам подумай — как ты заюзаешь чужую либу, если она не в курсе про твои ограничения `newMyObj` вместо `new MyObj`.
I>>>Она рассчитывает на GC, а у тебя нужно явно всё освобождать и тд.
I>·>Ага... А если ты заюзаешь чужую либу, а она там malloc делает и все кастомные аллокаторы фтопку.
I>В С++ аллокация кастомизируется
I>1 Многие либы поддерживают аллокаторы
То же и с java — если либа поддерживает расширение, то хорошо, если не поддерживает, то плохо.

I>2 можно дефолтный аллокатор соптимизировать под нужные сценарии
I>Это конечно трудная техника, но возможная. Что взамен в джаве, кастомный GC ?

Другая либа, обычно

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

dot>>>>Да пусть доказывает, он железный, зарплату не просит.
EP>>>У него есть жёсткие ограничения по бюджету времени — так как работает у конечных пользователей.
dot>>Так ему, в отличие от плюсов, не надо это доказывать для каждого кусочка кода, а только для активно выполняемого.
EP>На C++ зачем это доказывать? Мы же про EA говорим.
Чтобы писать надёжные программы.

EP>>>Оно бы грохнулось в тот же самый момент и без EA.
dot>>Да, ты похоже прав. EA лишь позволяет грохать сразу когда что-то перенесётся из кучи в стек|регистры, а это вряд ли произойдёт для больших массивов. А большие массивы просто будут грохаться прямо в Eden. Т.е. ArrayList может оказаться на стеке, а сам большой Object[] будет в куче. Оптимизация будет скорее в том, что вместо общего аллокатора будет использован Thread Local Allocaiton Buffer.
EP>Выгода также может быть на не компактифицирующем heap — поэтому я про него сразу и спросил.
С компактифицирующим heap и так всё понятно, он в C++ принципиально невозможен. Я говорю о том, что jvm может в рантайм принять решение о том, где можно разместить объект — в куче или стеке.

dot>>А Object[] может грохаться только если оптимизатор поймёт, что размер его маленький и его можно разместить на стеке.
EP>Я на C++ использую подобные массивы — small size optimization. При этом оно работает не только для стека, но и например для массивов вложенных в другие объекты.
Ты принимаешь решение в compile time — какой размер считать small.

dot>>Разница может быть заметна, если у тебя этот vector возвращается по значению из функции и его размер большой, что передачу by-value сделает неэффективой. А значит ты должен будешь его в unique_ptr обернуть или надеяться на RVO.
EP>Сейчас есть гарантия: в худшем случае что случится в описанном варианте это move, то есть никакой unique_ptr тут не нужен, также как и во многих других случаях.
Вот это и неудобно. Чуток хочешь переписать код и приходится приседать с тем что как возвращается и кто чем владеет. Даже простые рефакторинги типа extract method становятся нетривиальными.

EP>Да и RVO/NRVO прекрасно работает даже на старых MSVC.
Но код нужно писать определённым способом, чтобы этот RVO был возможен.

dot>>>>А если ты чуть поменяешь код и ссылка будет отправлена куда-то ещё, другому треду, попадёт в какой-нибудь контейнер, кеш, етс, то ничего не поломается, в отличие от unique_ptr.
EP>>>У него тоже ничего не поломается. Даже если бы это был просто vector<T>, без unique_ptr — то тоже ничего бы не поломалось

dot>>Это если голые указатели не использовать.
EP>Так я же говорю, их можно использовать когда нет владения. При передачи владения нужно это кодировать в типах.
Владение есть всегда.

EP>>>Это очевидный недостаток. Например есть текст, нужно передать куда-то отдельный абзац — на C++ достаточно например либо двух указателей, либо указателя и числа символов, либо просто указателя на начало абзаца. На Java же придётся ещё таскать ссылку на сам текст.
dot>>В общем да, есть такое. Хотя далеко не факт, что это может стать какой-либо проблемой... В типичном приложении у тебя скорее всего будет ссылка на какой-нибудь Document, по которому можно найти его текст. Поэтому будет достаточно пары индексов. А в большинстве случаев помещение двух или трёх чисел на стек — погоды не делает.
EP>На стеке да, а вот например если нужно хранить массив абзацев из разных документов — то уже будет существенная разница.
Уу... тогда ты в полный рост нарвёшься на проблемы с владением, временем жизни разных документов, что скорее всего выльется в массив который так же будет включать ссылки на документы.
А если очень надо такое соорудить в java, то можешь сделать индексы с уникальными оффсетами для каждого документа (по сути аналог указателей в единый массив адресов, как в С++).

dot>>>>Не понял, оно worst case (не путаем с amortised) не меняет же вроде, так же O(n).
EP>>>Меняет — поиск и удаление константы в худшем случае.
dot>>А добавление?
EP>С добавлением всё не так радужно. Но поинт в том, что линейная сложность хеш-таблиц — вполне себе проблема, которой вплотную занимаются.
В точности то же и с gc.

dot>>>>Комбинации чего?
EP>>>Структура данных * контейнер * алгоритм * etc. ЕМНИП даже в C# для разных структур generic даёт разные воплощения.
dot>>Круто, конечно. Но в горячем коде таких комбинаций обычно единицы. А остальному коду это всё не важно.
EP>У меня как раз в "горячем" коде их очень много.
Ок. Возможно у тебя такая специфика кода.

EP>>>Очень много, это практика, реальный код.
EP>>>Например вызвал сортировку для вектора со своим замыканием-предикатом — получил отдельный код оптимизированный конкретно под эту комбинацию.
dot>>Не факт, что это принесёт хоть какую-то пользу. compile time же.
EP>В смысле?
JIT тоже генерит код оптимизированный под конкретную комбинацию, но имеет больше информации — т.к. runtime.

EP>>>1. Если малое — то уж точно не нужна, тут разногласия нет.
EP>>>2. В описываемой тобой схеме получается: сначала latency на cache hit (пусть и небольшая) для того чтобы достать ссылку, потом latency на cache miss/поход в RAM, плюс кэш забивается лишними указателями, что снижает эффективность. Если же убрать индерекцию — то получается сразу поход в RAM, который есть и твоей схеме

EP>>>3. Ключ может хранится отдельно от значения, причём без индерекции.
dot>>Указатель это 8 байт. Если указуемое больше — то уже индирекция может помочь съэкономить на объёме горячей структуры.
EP>Ещё раз, индерекцию в RAM всё равно придётся делать, ты же предлагаешь ещё добавить к ней и индерекцию по кэшу.
Мы вроде о сканировании массива так, чтобы он помещался в кеш и подгружался последовательно. Когда отсканировали — берём значение рядом или индирекцией — другой вопрос.

dot>>>>Если значение маленькое, то это скорее всего будет примитив.
EP>>>С чего бы это?
dot>>Потому что примитив это те же 8 байт, что уже не так уж мало.
EP>На C++ там где удобно без проблем оборачиваю даже одно значение примитивного типа в класс

Да, система типов и шаблоны в С++ — мощнее, аж Turing complete.

dot>>by-value будет тупой YG, говорю же: зашли в функцию, создали объект, передали в глубь, там ещё что-то насоздавалось, там ещё глубже, пару циклов... а потом вышли и всё грохнули из YG пачкой.
EP>by-value работает не только вниз/вглубь, но и вверх, и даже вбок.
EP>А для случае когда нужно что-то прибить пачкой — используют например регионы/арены.
Это как? Кастомные аллокаторы что-ли?

dot>>>>Ну и кому эти микробенчмарки нужны?
EP>>>Тем кого интересует скорость

dot>>Для написания статьей о скорости может и сгодиться. А на практике обычно надо чтобы оно что-то полезное делало, а не быстрое.
EP>Так говоришь как будто быстрое означает не полезное.
Я говорю, что быстрое не означает полезное.

dot>>>>Ты давай пример системы на плюсах, компилированных под jvm.
EP>>>Я не знаю нормального компилятора C++ -> JVM. Есть даже мысли за-proof-of-concept'ить такой.
dot>>Потому и не знаешь, что принципиально невозможно.
EP>Что принципиально невозможно? C++ -> JVM? Возможно. Ещё раз, его даже в JS компилируют.
Возможно, но практически — бесполезно. JS — однопоточный.

dot>>>>Как дойдёт до времени отклика или тупо многопоточности (как там многопоточность в JS, кстати?), то всё и станет на свои места.
EP>>>Причём тут многопоточность JS? Какое время отклика? Ты о чём? Я мысли читать не умею.
dot>>Когда у тебя всё работает в одном потоке, то примерно почти все сложности с которыми сталкивается GC становятся не нужны. А значит и всё становится проще, и, естественно быстрее.
EP>1. В том тесте вообще GC остался за бортом, его действия не замеряли. Замеряли только обход массива с простой операцией.
EP>2. Причём тут вообще JS GC? В случае C++ -> JS — там практически все данные находятся в одном большом буфере.
Это я к тому, что при компиляции C++ -> JS проблемы с GC это самое меньшее о чём придётся беспокоиться.
Зачем это всё — вообще непонятно. Для вау-эффекта сойдёт, но практического смысла — маловато будет.

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

EP>>>Не факт что вообще будет отступление от дефолта. Так как в C++ аллокаций на порядки меньше.
EP>>>vector<tuple<tuple<tuple<tuple<tuple<tuple<int>>>>>>>(1u << 30) выделяется за одну аллокацию.
dot>>"new int[1<<30]" тоже за одну.
EP>Я специально же tuple показал — там по сути получается массив классов, в котором класс, в котором класс и т.д. — то есть типичный массив объектов. И в этом типичном случае на Java вырастают миллионы отдельных аллокаций, а на C++ — одна.
В итоге что тут получится — простенькая формула как по индексу массива и положению вычислить индекс внутри int[1 << 30]. Уж чего-чего, но без этого можно прожить.

EP>>>Да и специальный аллокатор по сути на удобство не влияет — поменял шаблонный аргумент и готово. Уж точно ни в какое сравнение с GC-Free.
dot>>Вот и считай, вместо кода специального аллокатора ты просто пишешь сразу GC-free код. Без лишних уровней абстракции.
EP>Ещё раз — в одном случае отличие от дефолта это несколько параметров, в другом изменение всего кода. Разница кардинальная.
EP>Поэтому аргументы типа "ну и что что весь код GC-free, зато у вас несколько параметров меняются" — несостоятельны.
"весь код" — это как-то пессимистично. На практике получаются гораздо более локальные рефакторинги.

EP>>>Сам же понимаешь что это передёргивание.
EP>>>Там где на Java будут нарезать массивы на структуры, по сути инстанциировать вручную все алгоритмы и контейнеры с этими структурами — на C++ будут обычные дефолтные структуры.
EP>>>Там где на Java будет нарезать на structure-of-arrays с теми же неудобствами — на C++ будет автоматическая библиотечная метапрограммная трансформация, которая выдаст такой же интерфейс как и прежде.
EP>>>Причём SoA требуются на порядки реже чем обычные структуры.
dot>>Да и оптимизация обычных структрур требуется на порядки реже.
EP>Реже чем что? Чем смирение с тормозами, повышенным энергопотреблением и т.п.?
Да нет особых тормозов. Ты, как приплюснутый, знаешь "как правильно писать на С++, чтобы не нарваься на битый указатель", а я, как жабнутый, "как правильно писать на Java чтобы gc не тормозил". Вот и всё. Ни на каком языке невозможно писать как в голову взбредёт и получать код, который работает хорошо.

EP>>>Есть в Mozilla, я тебе это уже неоднократно говорил. А вообще да — спроса на них практически нет

dot>>Для DOM/js афаир, но не для всего кода. Т.е. создать собираемую песочницу можно, но не "пишем на С++ с мусоросборщиком".
EP>Там это используется для interop JS (DOM?) <-> C++ — то есть не просто внутри JS.
Т.е. используется только для определённого вида объектов, с которыми без gc вообще не справиться.

dot>>>>во-вторых, эти расстрелы мало на что могут повлиять, очень ограниченный кусок кода.
EP>>>Действительно, подумаешь код не работает.
EP>>>Для C++ кстати есть готовые инструменты типа valgrind, которые гоняются параллельно тестам. А вот чем ловить расстрел буфера в off-heap?
dot>>Тестами, без всяких valgrind.
EP>Так в C++ будут и тесты и valgrind/etc. Об этом и речь, готовых инструментов на Java видимо нет, значит трата ещё дополнительных ресурсов.
off-heap объекты в довльно маленькой песочнице. Кода там порядка тысячи строк, что совсем мало для явы. И меняется этот код редко, ибо бизнес-логику не содержит.

EP>>>Конечно найдутся, сначала куча времени угробится на работу которую компиляторы умеют не одно десятилетие, потом куча времени угробится на отладку. Здорово.
dot>>Делаешь это только один раз. А потом можно десятилетия писать остальной код, не парясь с владением в каждой строчке кода.
EP>Даже тот "остальной" код лучше писать на более гибких и удобных языках. В итоге быстрый код на Java не удобен, медленный тоже

Что остаётся-то? Legacy и общая инертность?
Остаётся как минимум простота поддержки и разработки, скорость внесения изменений без страха что-то нечаянно поломать.

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

_>>> (в отличие от Жабки, где это без проблем):
_>·>И чем это отличается от Жабки-то?
_>Потому что в отличие от C++ как раз в жабке частенько встречает код вида x=null. Т.е. на практике реальность противоречит известным мифам об управление памятью в C++/Java.
Ты что-то фигню говоришь полную. Может что-то из давнего прошлого помнишь просто? Такое уж как минимум 6 лет неактуально.
Специально сейчас посчитал. В проекте 965 вхождений " = null" на ~2 миллиона строк. Притом большая часть из них вида

Some x = null;
if(...)
{
  x = ...;
}
use(x);

или

if(...)
{
...
   this.currentActiveSomething = ...;
...
}
else
{
...
   this.currentActiveSomething = null;
...
}

Т.е. конструкция такая используется, конечно, но никак к gc не относится.

_>>>От размеров проекта это не зависит. Ещё раз повторяю: если писать на C++, а не на "C с классами", то тот же delete или что-то подобное может вообще не встретить в проекте, в принципе.
_>·>Зависит. Если один человек напишет код и не будет сильно трогать после, то одно, а другое если у тебя проект с десяктами девов, продолжительностью в несколько лет, с релизами каждые две недели, то это совершенно другие правила игры.
_>·>Дело не в delete, а в &-ссылках или *-указателях.
_>Это только если разработка абсолютно бесконтрольная.
Или если в проекте используются сторонние библиотеки.

_>Если же в команде установлены хотя бы минимальные правила, то подобных проблем точно не будет, вне зависимости от размера команды. Если говорить о конкретном вопросе, то для его решения достаточно пары простейших правил:
_>- использование контейнеров stl (если конечно не требуется чего-то специфического)
_>- следование какой-то известной архитектуре организации многопоточности (например мне нравится модель акторов).
Архитектура многопоточности в первую очередь зависит от решаемых задач, а не личных предпочтений.

	От:	alex_public
	Дата:	13.10.15 13:33
	Оценка:

	От:	Somescout
	Дата:	13.10.15 13:38
	Оценка:

	От:	·
	Дата:	13.10.15 15:08
	Оценка:

	От:	·
	Дата:	13.10.15 15:26
	Оценка:

От:	Serginio1	https://habrahabr.ru/users/serginio1/topics/
Дата:	13.10.15 15:37
Оценка:

	От:	Evgeny.Panasyuk
	Дата:	13.10.15 16:50
	Оценка:

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	13.10.15 18:51
Оценка: