Почему я выбираю C++

Oxdeadbeef нахуй отсюда, срочно

например, FastParse в скале

Этот FastParse будет работать в compile-time в Scala?

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

у вас ошибка в тесте по первой ссылке: вы myvector.reserve(9999999) забыли написать

Тогда надо сделать аналогично и для кода на Си

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

Данная конкретная либа — нет. Множество других — да.

Например?

Например, для парсинга — https://github.com/sirthias/parboiled2 и https://github.com/begeric/FastParsers.

Спасиб. Все время забываю, что в Scala макросы добавили.

Это как так? В динамически выделяемой памяти, оператором malloc, никаких проверок нет и быть не может. Ты можешь выделить массив в 3 элемента, а обратиться к 33-му. Само по себе это не вызовит ошибки.

Всегда подозревал, что в google много разных какашко подъедателей.

Код внимательно посмотри http://pastebin.com/Xdhc7sx5
Строка 17 if ( (*arr)->size <= (*arr)->position)

тут дело не в самих плюсах, а в STL.

Где-то я даже читал, что само по себе программирование в ООП стиле дает в итоге ХУДШУЮ производительность, чем если все делать процедурно-императивно. Ну а если в плюсах писать как в Си и отключить все ненужности, связанные с обработками исключений, RTTI и прочее, скорость должна быть такая же

Я рекомендую посмотреть в сторону Scala.

В скале нет низкоуровневщины, которая есть в Си, плюсах, да даже в том же расте или в obj-c каком-нибудь. Для скалы требуется жирный рантайм (JVM) отчего его не впихнуть в микроконтроллеры, повышенное потребление ОЗУ. В скале есть обязательный GC, обязательный GC - плохо. Если б как в D можно было GC при желании вышвырнуть нафик и перейти на malloc-free и прочие подобные вещи - я не против, но я категорически против, когда мне этот GC навязывают.

Недостатков скалы, связанных с JVM и отсутствием первоклассной поддержки низкого уровня и других моделей памяти, я не отрицаю. С другой стороны, язык, который не навязывает модель памяти в итоге останется с экосистемой, раздробленной на сторонников различных моделей. «Ой, я хотел использовать либу X, но там модель памяти не той системы!» Понятно, что хочется всего и сразу, но скала является разумным решением для многих задач, для которых нужно метапрограммирование.

А принципиальных преград использовать другой рантайм для скалы нет. До недавнего времени скала поддерживала .NET-таргет, но он оказался никому не нужен, Scala.JS сейчас хорошо поддерживается и компилируется в JS. А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL.

Ты можешь выделить массив в 3 элемента, а обратиться к 33-му.

А какие проверки будут при обращении к элементу вектора?

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

Только вот у самой Scala и раньше была репутация слишком сложного языка, а теперь эта репутация, боюсь, только усиливается. Взять, хотя бы пример со стартовой страницы упомянутого вами LMS:

class Vector[T:Numeric:Manifest](val data: Rep[Array[T]]) {
  def foreach(f: Rep[T] => Rep[Unit]): Rep[Unit] =
    for (i <- 0 until data.length) f(data(i))
  def sumIf(f: Rep[T] => Rep[Boolean]) = { 
    var n = zero[T]; foreach(x => if (f(x)) n += x); n }
}

val v: Vector[Double] = ...
println(v.sumIf(_ > 0))

А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL.

Вопрос только в стоимости этого удовольствия.

Недостатков скалы, связанных с JVM

С++ не является инструментом моделирования ООП/ООД в отличие от Скалы/Явы. Классы C++ используются как форма записи низкоуровневых c-style структур.

А при помощи вышеупомянутого LMS можно

Можно всё. Вон на хаскеле можно через квазицитирование встраивать C. Это поможет? Нет.

У сверхвысокоуровневых языков типа скалы или хаскеля есть серьёзная проблема работы с низкоуровневыми объектами. И дело даже не столько в принципиальных тормозах FFI (их можно самортизировать), а в фундаментальной разнице между «мирами».

Даже в Go, эта разница уже существена.

Если отставить в сторону математическую (весьма нетривиальную) теорию, то мы получаем *сложнейший* языковой рантайм. В случае Скалы гвоздями прибитый к JVM, в случае хаскеля написанный на чистом C.

В C++ такого нет. Наоборот, в C++11 были ослаблены некоторые вещи, мешавшие взаимодействию.

Рантайм C++ даже с учётом изменений в C++11/C++14 и близко не приближается по сложности.

А при помощи вышеупомянутого LMS можно генерировать код хоть на C, хоть на JS, хоть на VHDL

на VHDL

Chisel или что-то другое?

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

Можно несколько примеров?

инструментом моделирования ООП/ООД

А что такое «моделирование объектно ориентированного дизайна»?

Для многих разработчиков это ничуть не лучше хардкорного C++ с шаблонами и Boost.

Ага, но в С++, со всей его сложностью, потребность есть. Опять же, в новых стандартах многое стало наоборот удобнее/проще, но очень распространено мнение, что "теперь язык целиком не знает никто". Сюда же нытьё про «раздутый стандарт».

Это я к тому, что скала чем хуже?

С другой стороны, язык, который не навязывает модель памяти в итоге останется с экосистемой, раздробленной на сторонников различных моделей. «Ой, я хотел использовать либу X, но там модель памяти не той системы!»

Выдуманная проблема. Одна из причин нужности того же С++ как раз в том, что он позволяет совмещать код с RAII, умными указателями, GC (в inkscape, например) и пр. с полностью ручным подходом как в С. И никому в голову не приходит на это жаловаться. Наоборот, многие к этому приходят. Microsoft запилила новый WinRT на С++, а C++/CLI заменила на C++/CX, где используется RC вместо GC. Apple тоже отказывается от GC в пользу ARC. В Rust отказались от GC. Александреску признал, что упор на GC в D был большой ошибкой. Сборка мусора как универсальное и навязываемое решение на все случаи жизни не прокатила. Это отличная идея, отлично работающая в большинстве задач, но есть много других задач, где нужен «язык, который не навязывает модель памяти».

нет низкоуровневщины
его не впихнуть в микроконтроллеры
обязательный GC - плохо

Я что-то пропустил, у тебя есть реальная (промышленная) задача, для которой это все имеет значение?

Взять, хотя бы пример со стартовой страницы упомянутого вами LMS

Отформатировано хреново конечно, а сложного-то там чего?

Есть реальные промышленные задачи писать RTOS для микроконтроллеров без MMU. Не важно, моя эта задача, или нет, но там эти скалы и прочие жабы идут лесом

Если использовать для доступа at(), то проверяется выход за границы. Если использовать оператор [], то вроде нет никаких.

Отформатировано хреново конечно, а сложного-то там чего?

На C++ подобную штуку можно было бы написать с таким же количеством закорючек. Но нашлась бы куча народу, для которых это было бы сложно.

Так же и здесь.

Проблемы языков вроде C++, Scala или Haskell в том, что программированием занимаются очень разные люди. Для кого-то потроха Boost-а — это открытая книга. А для кого-то шаблонная функция вроде accumulate — это сложно, распухание кода, непонятно во что раскрывается и т.д. При том, что вторые могут быть большими спецами в предметной области для которой они и пишут софт. И, как следствие, приносят больше пользы, чем первые.

Это я к тому, что скала чем хуже?

Насколько я могу судить, у Scala в рядах Java разработчика репутация такая же, как у C++ в рядах C-шников. Т.е. какому-нибудь махровому Java-программисту начать использовать преимущества Scala будет не проще, чем махровому C-шнику преимущества C++.

Да и менять C++ на Scala, без оглядки на специфику предметной области — это может быть тот еще совет :)

С++ не является инструментом моделирования ООП/ООД

Это вы мощно задвинули. Внушаить.

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

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

Проблема в том, что любая реальная программа взаимодействует как минимум с операционной системой через c-style интерфейсы. В сверхвысокоуровневом языке приходится нести затраты на реализацию такого взаимодействия, как на уровне рантайма, так и на уровне апи. Это не всегда приемлемо.

Отюда, и определённый «возврат к истокам» у основных вендоров.

но там эти скалы и прочие жабы идут лесом

Прошу заметить, жаба прекрасно живёт в смарт-картах. А там MMU и не пахло.

Прошу заметить, жаба прекрасно живёт в смарт-картах

Сразу видно теоретика. То, что живет на смарт-картах - это терминально убогий огрызок Java.

Там Java Card, она даже на уровне байткода с нормальной жабой не совместима

concepts lite завезут только может быть в 1z, и то не факт. Доклад Александра Фокина рассказывает неплохо

Отлично прокатила.
Просто сборка мусора ставит крест на интероперабельности с детерминизмом.

/0

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

Тут нет никакой проблемы. Вообще.

В сверхвысокоуровневом языке приходится нести затраты на реализацию такого взаимодействия, как на уровне рантайма, так и на уровне апи

Чушь.

Есть реальные промышленные задачи писать RTOS для микроконтроллеров без MMU

Понятно, с метапрограммирования математических алгоритмов лихо съехал на RTOS для микроконтроллеров :)

А почему это вдруг метапрограммирование несовместимо с написанием RTOS? https://leepike.github.io/Copilot/ вот смотри какая штука интересная

Не важно, моя эта задача, или нет, но там эти скалы и прочие жабы идут лесом

Так у тебя требования очень противоречивые. То «нормальное метапрограммирование» подавай, то «RTOS для микроконтроллеров». Ну нет «сейчас» одного языка, который бы удачно для всех задач подошёл. Так что придётся или разные инструменты использовать, ну или создавать «свой язык». Хотя можно и ограничиться жалобами на лоре на «несовершенство мира».

Там Java Card, она даже на уровне байткода с нормальной жабой не совместима

Шашечки или ехать? И не нужно мне пенять: я и так прекрасно знаю с чем она совместима, а с чем — нет. Факт остаётся фактом: ява с самого начала жила на весьма аппаратно ограниченных платформах.

Другое дело, что если Сану это было нужно (хотя в последнее время у них катастрофически не хватало ресурсов), то Ораклу уже нафиг не нужно.

Если использовать для доступа at(), то проверяется выход за границы.

Дык, в обсуждаемом коде нет at?

ну или создавать «свой язык»

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

На C++ подобную штуку можно было бы написать с таким же количеством закорючек.

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

Но нашлась бы куча народу, для которых это было бы сложно.

Так точно так же найдется и куча народу, для которой «угадай число» на бейсике - это ппц неподъемно. Я не вижу, как можно было бы упростить приведенный фрагмент (не выясняя даже, что такое Rep), сохраняя при этом все используемые в нем детали. Напиши хоть на псевдокоде, что ли.

Что же здесь сложного? Если не считать того, что авторы пустых строк пожалели, это простой идиоматический код, точно такой же будет на C# или на чем угодно. За двумя исключениями — вместо T используется обертка Rep[T], ну в этом и состоит сам фреймворк LMS, операции производятся не над объектами, а над их обертками, чтобы потом деревья можно было исполнять произвольным интерпретатором. Очень распространенный паттерн, см., например, http://underscore.io/blog/posts/2015/04/14/free-monads-are-simple.html И во-вторых, Manifest — это просто инструмент для интроспекции.

Насколько я могу судить, у Scala в рядах Java разработчика репутация такая же, как у C++ в рядах C-шников.

У меня такое же впечатление. Только, кажется, что мы делаем противоположные выводы.

Да и менять C++ на Scala, без оглядки на специфику предметной области — это может быть тот еще совет :)

Ну если кто-то, без дополнительных размышлений, поддастся такому совету, то выбор языка не самая большая его проблема. (:

С VHDL я ошибся, думал, что авторы Spiral его используют, но у них своя система.

Да зачем на псевдокоде? Там же есть пример, во что эта хрень раскрывается благодаря LMS:

var n: Double = 0.0
var i: Int = 0
val end = data.length
while (i < end) {
  val x = data(i)
  val c = x > 0
  if (c) n += x
}
println(n)

на все случаи жизни не прокатила.
Отлично прокатила.
Это не всегда приемлемо.

...

Но если я это на лор вброшу, отнесутся как к очередной «кодице» скорее всего, лол.

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

У меня такое же впечатление. Только, кажется, что мы делаем противоположные выводы.

Давайте сверим, что ли?

У меня вывод такой: чем сложнее язык, тем меньше должна быть проектная команда, тем тщательнее должен быть отбор в нее, тем более опытные люди в ней должны работать. Как следствие, за счет более мощного инструмента, за счет большего опыта и более высокой квалификации, за счет уменьшения количества связей (следствие небольшого объема команды) меньшими силами можно получать хороший результат (по качеству и по срокам). При использовании более примитивного инструмента потребовалось бы больше усилий и команда большего размера.

Правда, команду большего размера было бы проще собрать и проще сохранить (в том числе за счет более простой замены отдельных ее участников). Т.е. риски были бы меньше.

Так что, имхо, выбор Scala вместо Java, как и C++ вместо C (и даже C++14 вместо C++03) в большей степени определяется организационными проблемами, нежели техническими.

Ну если кто-то, без дополнительных размышлений, поддастся такому совету, то выбор языка не самая большая его проблема. (:

О том и речь :)