В конце февраля в Москве пройдёт конференция C++ Russia

Заменить три строчки кода С++, компилируемого в простой и эффективный машинный код, страницей страданий на шарпе,

Ну ессесно,решение компилируемое в машинный код вас не устраивает, вам бы очередной раз пораспинаться про офигенную тормознутость динамической типизации, не так ли? И кстати, в вашем «правильном решении» можно заменить один dynamic на Т, чтоб ненужно было указывать тип без необходимости.

страницей страданий на шарпе

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

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

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

Мне жаль пользователей ваших программ, раз они должны «формировать произвольное выражение» при их использовании.

При большом желании есть куча вариантов скомпилировать и выполнить код на С++ в процессе работы программы, от банального вызова компилятора с последующей загрузкой собранного бинарника до LLVM и так далее. Вот только зачем?

Но, к сожалению, в мире слишком распростренено мнение всяких неосиляторов, что любая нетривиальная работа с шаблонами - это не фонтан

Это проблемы неосиляторов, нет?

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

Мало что может быть ограниченнее и долбанутее шарповых генериков. Тем не менее, МС таки зачем-то впихнула их в шарп, как думаешь, почему?

При большом желании .... Вот только зачем?

ORMы, плагины и проч, то есть когда программе нужно работать с типами неизвестными на этапе компиляции, но при этом важна производительность. В Шарпе тут либо тормозные рефлекция и dynamic, либо генерация IL кода и деревья выражений. В крестах с этим, скажем прямо, беднее.

Мало что может быть ограниченнее и долбанутее шарповых генериков. Тем не менее, МС таки зачем-то впихнула их в шарп, как думаешь, почему?

Наверное затем же, зачем впихнула си-подобные макросы, только с обрезанной функциональностью. Я думаю, что нет никаких сомнений, что МС вполне могла бы реализовать полноценные сишные макросы, и раз это не сделано, значит так нужно. Так же и с дженериками и любыми другими фичами языка, где нужно соблюдать баланс между полезностью фичи и возможностью ей злоупотребить, нужно оценивать возможные последствия взаимодействия её с другими фичами, возникающие при етом edge cases и вытекающую из всего этого когнитивную нагрузку на программиста. И есть весьма распространненное мнение, что шарп занимает здесь золотую середину между джавой и крестами. И да, дженерики строго слабее шаблонов, но 90% кода дженериков - это вообще строго типизированные коллекции, а с тем мелким процентом из оставшихся 10 где их возможностей недостаточно, вы знаете что делать, благо есть выбор.

Оно мне надо, этот недоязык учить?

Раз пошла такая пьянка... Мне не лень и фортран потестировать :)

  program test
    integer*8 i
    real*8 sum /0.0/
    do i = 0, 100000000-1, 1
       sum = sum + dsin(real(i,8))
    enddo
    write (6, *) sum
  end program test

Угу, таки быстрее!

gleb@raccoon:~/src/hlam$ cpuinfo 
Intel(R) Core(TM) i5-3320M  Processor (Intel64 )

g++ -std=c++11 -o test test.cpp 
gleb@raccoon:~/src/hlam$ time ./test 
0.78201
real	0m3.850s
user	0m3.848s
sys	0m0.004s

ifort -o test test.f90
gleb@raccoon:~/src/hlam$ time ./test 
  0.782010319460671     

real	0m1.256s
user	0m1.257s
sys	0m0.000s

Спасибо за анонс, билет купил (правда с геморроем небольшим у тындекс-денег). Постараюсь быть.

P.S. Как я понял, дискуссия «c++ vs. python: the LORview» на конференции будет панельной :)

Может быть будет доклад о Rust, можно будет в обсуждении возобновить дискуссию :-)

А как вам такая пьянка?

<?php

function test() {
	$sum = 0.0;
	for($i=0; $i<100000000; ++$i)
		$sum += sin($i);
	return $sum;
}

echo test();

?>

$ time php ./test.php
0.78201031946082
real	0m27.121s
user	0m26.742s
sys	0m0.040s

Давай лучше на баше.

а как-то не удивлен... Для языка, основное применение которого — ожидать реакции пользователя, еще и неплохо... Ну вот еще ждем решения на хаскелле, D и руби :)

P.S.

Fortran (intel): 0.782010319460671 
php:                0.78201031946082

Разница в 13-м знаке после 10 миллионов итераций. Ну неплохо.

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

Насчет ORM: их есть и на C++. Да и для шарпа/дотнета наиболее употребительный ORM - NHibernate - не родной, а портирован с Java.

Так же и с дженериками и любыми другими фичами языка, где нужно соблюдать баланс между полезностью фичи и возможностью ей злоупотребить, нужно оценивать возможные последствия взаимодействия её с другими фичами, возникающие при етом edge cases и вытекающую из всего этого когнитивную нагрузку на программиста

Красиво сказано, надо забить в цитаты ;) На самом деле, ограничения женериков вытекают из того простого факта, что код обобщенных сущностей должен быть скомпилирован в сборку в отсутствие конкретных имплементаций этих сущностей, т.е. он может полагаться лишь на базовые свойства типов .net и на where-спецификации.

Оказвается сборщик мусора в планах стандартизации С++.

https://gcc.gnu.org/projects/cxx0x.html

(Minimal support for garbage collection and reachability-based leak detection)

Тогда не со мной. Я про питон ничего сказать не могу.

т.е. он может полагаться лишь на базовые свойства типов .net и на where-спецификации.

т.е. если конкретней, то все вызовы в таком коде могут быть только динамическими, и статические методы не могут вызываться просто по определению, а иначе мы могли бы просто return T.operator+(a, b); и всего делов. Могли бы ли быть статические методы быть не такими уж статическими, а зависеть от вызываемого типа T, то есть они были бы эдакими методами класса? Наверняка. Усложнило бы это язык и его разработку? Безусловно. Были взвешены все за и против и результат известен.

И главное, можно ли без этого написать быстрый, но в то же время простой код? Абсолютно. Ведь на самом деле правильный ответ состоит не в строительстве велосипедов, а в том, чтоб скачать библиотечку, и просто в итоге написать return Operator.Multiply(a, b);

time ./a.out
0.78201

real 0m0.269s
user 0m16.983s
sys 0m0.119s

grep processor /proc/cpuinfo | wc -l

80

grep model/proc/cpuinfo

model name      : Intel(R) Xeon(R) CPU E7- 4870  @ 2.40GHz