LINUX.ORG.RU

Какое же говнище этот ваш С++

 


11

7

Решил намедни углубить свои знания по плюсам, чувствуя, что скоро нехило так потребуются по работе. Теперь сижу, обмазываюсь тут всякими трупами страусов, Скоттом Майерсом и другими. Г-пди, как же можно на этом писать, особенно после знания божественных лиспов, хаскелей и прочих матанских агд (sic!). Это какая-то пытка, честное слово, мне натурально мерзко и противно читать как люди пытаются вырезать гланды через задний проход да ещё и хвалятся этим, поглядите, мол, как это круто. Такое ощущение, будто плюсисты все поголовно латентные мазохисты.

template <typename T>
class Rational
{
    public:
    ...
    friend const Rational operator*(const Rational& lhs, const Rational& rhs)
    {
        return Rational(lhs.numerator() * rhs.numerator(), // same impl
            lhs.denominator() * rhs.denominator()); // as in Item 24
    }
}

An interesting observation about this technique is that the use of friendship has nothing to do with a need to access non-public parts of the class. In order to make type conversions possible on all arguments, we need a non-member function (Item 24 still applies); and in order to have the proper function automatically instantiated, we need to declare the function inside the class. The only way to declare a non-member function inside a class is to make it a friend. So that's what we do. Unconventional? Yes. Effective? Without a doubt.

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

Перемещено mono из talks

★★★★★

Последнее исправление: mono (всего исправлений: 1)

Ответ на: комментарий от anonymous

а чо, если в задаче надо несколько разных фич, то использовать 100500 языков?

x4DA ★★★★★
()
Ответ на: комментарий от tailgunner

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

А так же еще сказали, что есть проекты в Haskell, которые это «почти» адресуют: repa для числовых задач и структуры данных тапа cache oblivious. Разница вот в чем, cache oblivious — это не совсем то, о чем говорил комментатор Nicola Bizzoca. Кто не в курсе, может разницу и не понять. Никола говорил о структурах данных cache-aware. А они более производительны, чем те, которые о кэше ничего знать не хотят, кроме факта его наличия.

Далее... Хорошей единой STM не существует. Для разных объемов данных нужны разные механизмы персистентности. Иначе будет гигантский оверхед. Вбивать в язык одну модель STM на все случаи жизни — не самое лучшее решение. Кто знает Haskell, ткните меня носом если это не так.

Вот пример, того, что не всё так просто. Есть структуры данных типа lock-free. Они должны быть более быстрыми при массивном многопоточном доступе. Но возникает вопрос: а насколько массивном? Дело в том, что такие структуры данных заметно медленнее своих однопоточных аналогов в режиме однопоточного доступа. Т.е. выигрыш в производительности от перехода на lock-free контейнеры может и не проявиться вовсе. Всё зависит от нагрузки.

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

Я только за Haskell. Но что-то мне кажется, что при его сравнении с С++ нам чего-то сильно не договаривают. Bartosz Milewski это показывает.

aist1 ★★★
()
Ответ на: комментарий от aist1

в случае С++ у меня есть возможности выжать из архитектуры максимум возможного.

Я только за Haskell. Но что-то мне кажется, что при его сравнении с С++ нам чего-то сильно не договаривают. Bartosz Milewski это показывает.

Я только против Haskell, но я вижу, что Bartosz Milewski говорит о composable abstractions (новый баззворд, ага) и о том, что стандартные возможности Си++ плохо стыкуются друг с другом. А в ответ на это - «зато мы можем выжать из архитектуры всё».

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

этот бартосз какой-то человек, которому хаскель съел мозг.

x4DA ★★★★★
()
Ответ на: комментарий от tailgunner

А, вот в чем дело. Да, ты правильно говоришь. Абстракции плохо стыкуются. Вопрос в том, чья это проблема? Виноват ли Страуструп, что язык «is not perfect»? Виноваты ли члены комитета по стандартизации языка, которые долго не могли договориться между собой? Виноваты ли программисты, которые никак не могут состыковать эти абстракции?

Я думаю, что у всего есть стоимость. В том числе есть стоимость сопряжения абстракций. В С++ с сопряжением поступили точно так же, как с библиотеками — оставили на откуп программистам. Это хорошо или плохо? Я не буду отвечать на этот вопрос, я не знаю.

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

Много ли таких случаев? Внезапно, да. Очень много. Как оказалось (было доказано), что большинство из всех возможно существующих строк несжимаемы. Как следствие, реальные программы (а любая программа - это сжатое представление некоей строки преобразований) всегда будут сложны, вне зависимости от языка программирования. И DSLи не помогут. Они как раз адресуют очень разреженное множество хорошо сжимаемых строк.

Иными словами, в С++ абстракции не стыкуются не из-за отсталости дизайнеров языка, как думают многие.

aist1 ★★★
()
Ответ на: комментарий от aist1

Вопрос в том, чья это проблема?

«Чья»? Программистов на Си++. Причина проблемы - изначальное желание Страуструпа делать язык надмножеством Си. На этот зыбкий фундамент с годами нагромождается всё больше фич.

В С++ с сопряжением поступили точно так же, как с библиотеками — оставили на откуп программистам

Нет. В Си++ очень низкоуровневые средства построения абстракций, в результате взаимодейтвие построенных абстракций тоже низкоуровневое. Сколько было загадок «почему этот корректно выглядящий код тонко сбоит»? И ведь ответы на эти загадки совершенно логичны, но для того, чтобы эти ответы получить, нужно мысленно оттранслирвнслировать Си++ код на уровень Си (или даже ниже). Т.е. ты должен знать детали, которые, по-хорошему, не должны никого волновать.

в С++ абстракции не стыкуются не из-за отсталости дизайнеров языка

В основном не из-за нее, конечно. Но история с шаблонным метапрограммированием, которое фактически было открыто, а не спроектировано, намекает.

tailgunner ★★★★★
()
Ответ на: комментарий от ckotinko

> я со своей осью сломался на ACPI. это звездец какой-то.

Понятно что твой Bolgenos не взлетит и ты - лох корявый и неосилятор простой адресной арифметики. Тебе не ОС писать, бездарь, а говнокод для бухалтеров,ага!

anonymous
()
Ответ на: комментарий от tailgunner

Сколько было загадок «почему этот корректно выглядящий код тонко сбоит»?

Ты имеешь в виду undefined behavior на ровном месте?

В основном не из-за нее, конечно. Но история с шаблонным метапрограммированием, которое фактически было открыто, а не спроектировано, намекает.

Да, дивная была история... Но с другой стороны, добиться полноты по тьюрингу совсем не сложно. Достаточно просто рекурсии. Рекурсию сделали, чтобы было. А потом пришел Александреску и понеслась. Выяснилось, что программы писать можно, но не сильно приятнее, чем на голой машине тьюринга. Но это единственная серьезная претензия к шаблонам. В остальном они, как мне кажется, вполне нормально интегрированы в систему типов языка. Поправь меня, пожалуйста, если я упускаю что-то серьезное.

aist1 ★★★
()
Ответ на: комментарий от aist1

Сколько было загадок «почему этот корректно выглядящий код тонко сбоит»?

Ты имеешь в виду undefined behavior на ровном месте?

Нет. Я имею в виду, например, первую версию auto_ptr (которая была в драфте стандарта).

Поправь меня, пожалуйста, если я упускаю что-то серьезное.

История с метапрограммированием началась еще в середине 90-х, со случайного открытия expression templates, ЕМНИП. А может, и раньше.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Я имею в виду, например, первую версию auto_ptr (которая была в драфте стандарта).

У тебя есть ссылки или хотя бы ключевые слова? Ну а то, что язык во многих местах контринтуитивен — это да. И сплошные UB на ровном месте. Радует то, что в следующих версиях clang будет UBSanitizer.

История с метапрограммированием началась еще в середине 90-х, со случайного открытия expression templates, ЕМНИП. А может, и раньше.

Если я правильно помню, шаблоны появились в С++98?

aist1 ★★★
()
Ответ на: комментарий от aist1

Я имею в виду, например, первую версию auto_ptr (которая была в драфте стандарта).

У тебя есть ссылки или хотя бы ключевые слова

http://www.gotw.ca/gotw/025.htm

Если я правильно помню, шаблоны появились в С++98?

Шаблоны были описаны уже во 2-м издании «The C++ programming language», вышедшем в 1991. Первые реализации в рамках Cfront - ~1988.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Нет. Я имею в виду, например, первую версию auto_ptr (которая была в драфте стандарта).

Ну там вроде как с копирующим конструктором были проблемы, который сам по себе ацкое изобретение.

ebantrop
()
Ответ на: комментарий от tailgunner

Разобрался. Они изменили операционную семантику копирования auto_ptr (на перемещение) и огребли кучу нерешаемых проблем с контейнерами. По некотором размышлении я всё же пришел к выводу, что это хороший пример бага в дизайне, приводящего к несовместимости абстракций, как ты это назвал.

Как с твоей точки зрения, на сколько С++11 в этом смысле лучше предыдущего стандарта?

aist1 ★★★
()
Ответ на: комментарий от ebantrop

Ну там вроде как с копирующим конструктором были проблемы

Пойнт в том, что предложение с этим багом дошло до драфта стандарта (т.е. наверняка преодолело как минимум одно ревью); скорее всего, аналогичное средство использовалось где-то «в поле'. Т.е. вполне квалифицированные люди отнюдь не сразу заметили проблему - это к вопросу о взаимодействии абстракций.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

это, конечно, ерунда и офтоп, но твой комментарий 666-ой в этом треде +)

Virtuos86 ★★★★★
()
Последнее исправление: Virtuos86 (всего исправлений: 1)
Ответ на: комментарий от aist1

к несовместимости абстракций, как ты это назвал.

Я просто пытаюсь перевести модное словосочетание "(non-)composable abstractions".

Как с твоей точки зрения, на сколько С++11 в этом смысле лучше предыдущего стандарта?

Я перестал программировать на Си++ еще до выхода C++98 и сейчас пытаюсь наверстать упущенное. Мне нравится C++11, добавки вроде unique_ptr. Но, как правильно заметил это самый Бартош: «There are countless ways of doing the same thing — almost all of them either plain wrong, dangerous, unmaintainable, or all of the above. The problem is that most code compiles and even runs. The mistakes and shortcomings are discovered much later»; и новый стандарт - добавка к этим countless ways.

КМК, на Си++ лучше не программировать без зверского (но разумного!) соглашения о кодировании. Есть где-то такое соглашение, написанно с учетом C++11? Гугловое не предлагать.

tailgunner ★★★★★
()
Ответ на: комментарий от aist1

Далее... Хорошей единой STM не существует. Для разных объемов данных нужны разные механизмы персистентности. Иначе будет гигантский оверхед. Вбивать в язык одну модель STM на все случаи жизни — не самое лучшее решение. Кто знает Haskell, ткните меня носом если это не так.

у haskell (и нек других функциональных языках) есть одно отличное свойство, используемое в STM, он чистый, а все проблемы в перетаскивании STM натыкаются на проблему персистентности. В ФП же все структуры являются персистентными по построению.. такие дела. Ну и composability сюда же.

Вот пример, того, что не всё так просто. Есть структуры данных типа lock-free. Они должны быть более быстрыми при массивном многопоточном доступе. Но возникает вопрос: а насколько массивном? Дело в том, что такие структуры данных заметно медленнее своих однопоточных аналогов в режиме однопоточного доступа. Т.е. выигрыш в производительности от перехода на lock-free контейнеры может и не проявиться вовсе. Всё зависит от нагрузки.

извини, а к чему ты это?

Всё зависит от нагрузки... В том-то и дело, что в случае С++ у меня есть возможности выжать из архитектуры максимум возможного.

В любом компилируемом языке есть возможность выжать из архитектуры всё, например включив ffi вызовы, или включив C код прямо в программу (PrimOps в haskell). Но практика показывает, что нужно это очень редко.

Потому что, например, когда недетерминированный GC вбивают гвоздями в программную платформу, это дает всю платформу недетерминированной, без вариантов. Гарантированного времени отклика на запрос на ней уже не добиться.

Регионы и инкрементальные gc, наверное придумали случайно.. Хотя в общем случае проблемы, действительно, есть :)

qnikst ★★★★★
()
Ответ на: комментарий от tailgunner

там случайно не в контексте STM? где (без STM) если у тебя есть 2 операции, ставящие локи, ты уже не можешь их просто «объединить» в одну операцию, которая делает 2 вещи, не вводя дополнительного кода. Если так, то держи статью: https://research.microsoft.com/en-us/um/people/simonpj/Papers/stm/stm.pdf

qnikst ★★★★★
()
Последнее исправление: qnikst (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Я перестал программировать на Си++ еще до выхода C++98

C++03, сорри.

tailgunner ★★★★★
()
Ответ на: комментарий от qnikst

там случайно не в контексте STM?

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

Но я знаю, как работает STM :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

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

это конечно не технический термин, но и не buzzword, т.е. там говорится, что если есть операции foo, bar, которые используют какие-то ресурсы, то мы можем писать foo;bar, bar;foo, atomically $ foo;bar, не боясь дедлоков, рейсов и прочей белиберды. Иногда его используют и шире - для всяких комбинаторов, которые можно переиспользовать, и в ФП это практикуется, но там с примеры не на поверхности валяются.

Но я знаю, как работает STM :)

почитай первые главы статьи, меньше 15 минут уйдёт, а общее понимание того, что там и зачем, будет :)

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

это конечно не технический термин, но и не buzzword

Я пока не ухватываю общего значения этого термина. Если с STM понятно, то вот, например, в Rust делают composable API для Option (что далеко от всякой параллельности): https://mail.mozilla.org/pipermail/rust-dev/2013-September/005688.html

почитай первые главы статьи, меньше 15 минут уйдёт

Armin Rigo, который делает STM для PyPy, перерыл кучу материала, так что я читал и эту статью тоже :)

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Я пока не ухватываю общего значения этого термина.

да согласен, в этом общем случае контекст нужен, а то можно разное понимать.

Armin Rigo, который делает STM для PyPy, перерыл кучу материала, так что я читал и эту статью тоже :)

тогда ты знаешь, как работает STM во всяком случае в haskell.

qnikst ★★★★★
()
Ответ на: комментарий от tailgunner

Я просто пытаюсь перевести модное словосочетание "(non-)composable abstractions".

Я под этим термином понимал немного другое. Например, то, что деструктор не должен бросать исключение. Это может привести к UB, хотя компилятор это делать не запрещает. Т.е. исключения есть, и бросать их можно, но нельзя.

В случае же auto_ptr мы имеем нарушение операционной семантики присваивания. Я так это понимаю, могу ошибаться с термином.

Но, как правильно заметил это самый Бартош: «There are countless ways of doing the same thing — almost all of them either plain wrong, dangerous, unmaintainable, or all of the above. The problem is that most code compiles and even runs. The mistakes and shortcomings are discovered much later»

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

Может быть претензия к компилятору, что он не мешает делать неправильно. Он мог бы хотя бы предупреждение об UB делать, но доверяет программисту. Решение этой проблемы смотри ниже...

КМК, на Си++ лучше не программировать без зверского (но разумного!) соглашения о кодировании. Есть где-то такое соглашение, написанно с учетом C++11? Гугловое не предлагать.

Думаю, можно сказать, что есть. Только реализовывать его нужно не в виде документа, а в виде инструмента верификации кода. Т.е. я в своем проекте сам ограничиваю операционную семантику (сопрягаю абстракции) так, как мне надо и эти ограничения реализую в виде, например, плагина к clang. Дешево и сердито. И, мне кажется, что другого пути нет.

aist1 ★★★
()
Ответ на: комментарий от aist1

В добавление к этому бесконечному количеству способов сделать одну и ту же вещь неправильно есть бесконечное количество способов сделать её правильно.

...и это бесконечно большие величины одного порядка, да?

Есть где-то такое соглашение, написанно с учетом C++11? Гугловое не предлагать.

Думаю, можно сказать, что есть.

Где? Только более-менее общепринятое, а не твой собственный плагин к clang.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

...и это бесконечно большие величины одного порядка, да?

Всё, что я пока могу сказать, что это множества одной кардинальности. Интересно другое. Какова вероятность того, что случайно сгенерированная программа на C++ будет семантически корректной и без UB. Но тут надо сложные выкладки делать, с ходу я не скажу.

Где? Только более-менее общепринятое, а не твой собственный плагин к clang.

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

Из того, что есть — это статические анализаторы кода. Но это не совсем то, о чем мы говорим.

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

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

aist1 ★★★
()
Ответ на: комментарий от qnikst

В ФП же все структуры являются персистентными по построению.. такие дела.

смотри ниже...

извини, а к чему ты это?

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

Структуры данных типа lock-free имеют значительно большие скрытые константы. И применение этих структур в качестве своих замены однопоточных аналогов только привносит ненужный оверхед.

Точно так же полностью функциональные структуры данных привносят никому не нужный оверхед там, где функциональная семантика не нужна. Кто-нибудь задумавался о том, каковы накладные расходы на представление персистентных структур данных посредством 2-3 thinger tree? На нем можно всё, что нужно, сделать, но сколько это будет стоить?

В любом компилируемом языке есть возможность выжать из архитектуры всё, например включив ffi вызовы, или включив C код прямо в программу (PrimOps в haskell). Но практика показывает, что нужно это очень редко.

Вот человек выше давал ссылку на исследовательскую реализацию STM в Haskell. Низкоуровневая реализация там на сделана на C.

Это обязательно было делать? Что получится, если всё сделать на Haskell? Будет много «нефункционального» кода или будет заметно медленнее?

Мы можем пользоваться FFI или JNI, но при этом подключаемый код не охватывается оптимизациями. Например, не инлайнится. Нельзя сказать, что мы выжимаем из архитектуры _всё_.

aist1 ★★★
()
Ответ на: комментарий от tailgunner

Сначала нужно понять, что именно он будет проверять.

Ну вот, например, у меня в проекте есть требование, чтобы некоторые классы были тривиальными и не содержали полей-указателей. Первое требование можно проверить средствами языка, а второе — уже только плагином.

Другой пример. Предположим, ты используешь паттерн частичных классов, собирая некий большой класс из повторно-используемых «кусочков» (смотри, например, генератор линейной иерархии Александреску). Каждый из этих кусочков подразумевает некоторый контекст из имен и типов, которые он использует (контракт). Несоответствие типов в лучшем случае приведет к непонятной ошибке компиляции. В худшем — к трудно диагностируемой ошибке в рантайме. Плагин будет проверять выполнение всех контрактов в твоем приложении.

И т.д.

aist1 ★★★
()
Ответ на: комментарий от r

Нахрена по твоему такие платформы как жаба и .NET вообще создаются?

Чтобы призвать в разработчики большее количество индусов за счет уменьшения сложности при автоматическом управлении памятью. Серьезным дядям нужно делать серьезные деньги, вот они и способствуют появлению и популяризации инструментов, увеличивающих скорость и уменьшающих сложность разработки. Только вот при этом на пожор ресурсов кладется болт, т.к. этим самым дядям проще купить железо помощнее. C++ конечно страшен и перегружен, но ты действительно считаешь java/.NET передовыми технологиями?

m0rph ★★★★★
()
Ответ на: комментарий от m0rph

Чтобы призвать в разработчики большее количество индусов за счет уменьшения сложности при автоматическом управлении памятью

Я так понимаю всякие конвеерные сборки и роботов тоже ради индусов производят. Надо по старинке - в кузницах. Картофан - лопатой. Плуг - на коне. Выкинуть все комбайны! Это же для индусов. Заниматься проблемами которыми можно не заниматься - это конечно признак профессионала, а не идиота.

C++ конечно страшен и перегружен, но ты действительно считаешь java/.NET передовыми технологиями?

Со сравнению с плюсами? Да это просто мегасупер. По той простой причине что плюсы сейчас затычка в месте более элегантного решения для которого пока не сделали. А _хорошего_ в них ничего нет. Как язык - уродство. Как платформа - какая платформа? От того что пока заменить нечем в определенных областях - не делает их сколь нибудь хорошим инструментом. You dont choose c++ you stuck with c++.

r ★★★★★
()
Ответ на: комментарий от r

Надо по старинке - в кузницах. Картофан - лопатой. Плуг - на коне.

В ручном управлении памятью нет ничего страшного, только отсутствует бесполезная трата процессорного времени на сборку мусора. Даже в C++ сейчас за счет unique_ptr/shared_ptr/weak_ptr уже все сильно упрощается.

По той простой причине что плюсы сейчас затычка в месте более элегантного решения для которого пока не сделали.

Благодаря этой самой затычке современный софт еще хоть как-то шевелится. А так, конечно, соглашусь, хотелось бы более человеческую альтернативу. Только без VM и без прибитого гводзями (читай с отключаемым) GC, т.к. эти вещи нужны совсем в другой нише. Ну а если уж идти по пути платформы с VM, то встраивать VM нужно в ядро ОС, а не пускать отдельным потоком/процессом.

m0rph ★★★★★
()
Ответ на: комментарий от r

Я так понимаю всякие конвеерные сборки и роботов тоже ради индусов производят. Надо по старинке - в кузницах. Картофан - лопатой. Плуг - на коне.

Так роботы и конвеерные сборки работают быстрее.

anonymous
()
Ответ на: комментарий от m0rph

А я думал, что жабу создали для кросплатформености. Понятно, что эту задачу просрали и сейчас пытаются придумать другеи причны возникновения этого уродца

vromanov ★★
()
Ответ на: комментарий от r

но ты действительно считаешь java/.NET передовыми технологиями?

Со сравнению с плюсами? Да это просто мегасупер.

Жжош. C# и _особенно_ java - это такая кастрированная по самые гланды чуть причесанная версия плюсов для интерпрайз-обезьянок. То что там из этого исторически получилась платформа - это перерастание *огромного* количества биомассы в качество и тестирование, с такими усилиями и таким баблом которое вложено в джаву оно должно было уже обрасти свой разум, превосходящий человеческую цивилизацию на три порядка.

От того что пока заменить нечем в определенных областях - не делает их сколь нибудь хорошим инструментом.

С++ это не айс, но говорить, что по сравнению с ними java это «просто мега супер» «передовые технологии» это шиздец. *Особенно*, если сравнивать с современными плюсами с кучей версий разных умных указателей. Java это пережиток прошлого с рождения, просто костыль оказвшийся в нужном месте в нужное время, вынесенный в массы на шикарном хайпе.

alienclaster ★★★
()
Ответ на: комментарий от ugoday

В каком месте жаба --- версия плюсов?

Во всех: синтаксис, семантика, ооп, нейминг, культура.

alienclaster ★★★
()
Ответ на: комментарий от aist1

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

ты зачем пытаешься играть в КО, и что ты пытаешься донести?

Структуры данных типа lock-free имеют значительно большие скрытые константы. И применение этих структур в качестве своих замены однопоточных аналогов только привносит ненужный оверхед.

осталось объяснить при чем здесь ФП и haskell в частности..

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

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

Кто-нибудь задумавался о том, каковы накладные расходы на представление персистентных структур данных посредством 2-3 thinger tree?

к чему здесь это?

Вот человек выше давал ссылку на исследовательскую реализацию STM в Haskell. Низкоуровневая реализация там на сделана на C.

ник человека дававшего ссылку прочитай...

Это обязательно было делать?

да.

Что получится, если всё сделать на Haskell?

зачем?

Будет много «нефункционального» кода или будет заметно медленнее?

будет глупо :)

Мы можем пользоваться FFI или JNI, но при этом подключаемый код не охватывается оптимизациями. Например, не инлайнится. Нельзя сказать, что мы выжимаем из архитектуры _всё_.

часть про PrimOps ты пропустил т.к. не знаешь что это, или почему? Можно точно сказать, что для того, чтобы делать утверждения про какой-то предмет, нужно разбираться в нём хотя бы на среднем уровне.

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

ты зачем пытаешься играть в КО, и что ты пытаешься донести?
к чему здесь это?
да.
зачем?
будет глупо :)

Ты, наверное, не видел, с чего эта часть разговора началась. Я привел ссылку на блог Бартоша Милевски, который выдал свеженькую критическую статью по результатам прошедшего GN'13. Если коротко, то как в С++ всё неправильно и как в Haskell всё правильно. Отсюда и дальнейший разговор пошел. В комментариях к тому блогу Бартошу объяснили, что в Haskell не хорошо, глазами разработчика С++. А именно, что парадигма Haskell приводит к неизбежному оверхеду, о котором предпочитают не говорить.

В конце-концов мы с тобой пришли к тому, что кое-какие вещи на хаскеле, который так хвалит Бартош, делать не стоит. Будет глупо. Делать их стоит на С++, или на С.

часть про PrimOps ты пропустил т.к. не знаешь что это, или почему? Можно точно сказать, что для того, чтобы делать утверждения про какой-то предмет, нужно разбираться в нём хотя бы на среднем уровне.

Я сначала думал, что он по-другому работает, но потом вспомнил, что GHC компилирует в промежуточный С. Да, это может быть эффективно.

aist1 ★★★
()
Ответ на: комментарий от aist1

Я привел ссылку на блог Бартоша Милевски, ...

ну не стоит же его так серьёзно воспринимать :) он, кстати, прикольный дядька, я общался с ним, когда в FP Complete пытался устроиться.

А именно, что парадигма Haskell приводит к неизбежному оверхеду, о котором предпочитают не говорить.

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

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

это справедливо для любого языка.

Делать их стоит на С++, или на С.

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

qnikst ★★★★★
()
Ответ на: комментарий от qnikst

ну не стоит же его так серьёзно воспринимать :)

Да я не в претензии. К С++ очень много вопросов, которые выглядят вовсе не беспочвенными. Я просто хочу разобраться, что за ними стоит реального. Позиция Бартоша здесь выглядит для меня тенденциозной.

Performance critical, конечно, писать можно, но это нужно уметь.

Это справедливо для любого языка. И для С++ — в первую очередь. Если программа пишется на С++, это не значит, что она будет быстрой. Это не значит, что её производительность будет предсказуемой. Это значит только то, что программиста поимеет куча головоломок, предоставляемых дизайнерами языка.

Ценность С++ мне видится в гибкости его мультипарадигменности. Хотя эта гибкость дается довольно дорого. Мне самому кажется, что исследовательские задачи типа разработки новых алгоритмов лучше решать на чем-то типа Haskell.

это справедливо для любого языка.

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

Итак, [claim] любая программа, моделирующая достаточно сложные и большие объекты и процессы реального мира, будет сложна на любом языке программирования.[/claim]

Сложность здесь определяется в рамках теории алгоритмической информации.

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

aist1 ★★★
()
Ответ на: комментарий от tailgunner

Пойнт в том, что предложение с этим багом дошло до драфта стандарта (т.е. наверняка преодолело как минимум одно ревью);

Офигеть как бывает. Я не знал.

По моему опыту отстрел ног с плюсах происходит в основном из-за копирующих конструкторов. По крайней мере у меня, и как видно не только у меня, но еще и у гуру пилящих стандарт.

В 11 rvalue вкрутили, что не может не радовать.

ebantrop
()
Ответ на: комментарий от aist1

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

согласен.

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

в общем случае не согласен с обоими пунктами.

qnikst ★★★★★
()
Ответ на: комментарий от alienclaster

То что там из этого исторически получилась платформа - это перерастание *огромного* количества биомассы в качество и тестирование

Нет - это как раз отсутствие 100500 способ делать желаемое неправильно, что ведет к «неправильным библиотекам» что ведет к отсутствию платформы. Соглашения прошитые в компилятор из устного народного творчества это сделали.

, с такими усилиями и таким баблом которое вложено в джаву

А с++ пилит кучка энтузиастов чтоле?

Java это пережиток прошлого с рождения,

Это сейчас уже так. А на практике мега системы на жабе пишутся и это удается лучше чем на ++. На ++ в лучшем случае потом «переписываются» полумеханически.

r ★★★★★
()
Ответ на: комментарий от vromanov

я думал, что жабу создали для кросплатформености. Понятно, что эту задачу просрали

Задачу успешно решили.

tailgunner ★★★★★
()
Ответ на: комментарий от qnikst

в общем случае не согласен с обоими пунктами.

Почему? Можешь обосновать? (я не жду формализмов, просто качественно)

Чтобы было понятнее, какую сложность я имею в виду.

Рассмотрим, как выбор языка описания влияет на значение K и покажем, что эффект от смены языка описания является ограниченным.

aist1 ★★★
()
Ответ на: комментарий от r

отсутствие 100500 способов делать желаемое неправильно

справедливости ради, стоит отметить что в Java мест с радиусом кривизны достаточным для выстрела себе в ногу «из верёвки» предостаточно

shty ★★★★★
()
Ответ на: комментарий от r

Нет - это как раз отсутствие 100500 способ делать желаемое неправильно

Ну да, это конечно тоже - помноженное на биомассу.

с такими усилиями и таким баблом которое вложено в джаву

А с++ пилит кучка энтузиастов чтоле?

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

Java это пережиток прошлого с рождения,

Это сейчас уже так.

Да нет, это сразу так и было очевидно - что язык говно, и можно было вместо него сразу же какую-нибудь хотя бы скалу пропихнуть в массы.

А на практике мега системы на жабе пишутся и это удается лучше чем на ++.

Т.н. интерпрайз? Безусловно.

alienclaster ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.