The new C++11 has copy and move semantics, iterators, range-based for loops, lambdas, the auto keyword, smart pointers, and a whole slew of new data structures and algorithms in the STL.
Ага, ага. А copy-on-write в STL НЕТУ. А realloc-а в std::vector НЕТУ. До сих пор НЕТУ стандартизированного ABI (весь этот манглинг-деманглинг каждый может городить, как ему вздумается). Нормального способа работать с типами (SFINAE - костыль, и этот enable_if через SFINAE накостылен) НЕТУ. Метапрограммирование в плюсах сосет.
а урл у статьи why-im-choosing-c.
собсна, против плюсов ничего не имею. у всех языков есть своя ниша для разработки. в С-образных языках (кроме до-диеза) использование возможностей языка в значительной степени зависит от опыта программиста и некривых рук. в руках тупого нуба плюсы могут оказаться страшнее атомной бомбы.
It's seems as if the language committee has been observing all the innovation going on in the world at large, and has done a great job of reacting to the times.
Чухня. Главная причина, почему C++11 рулит и педалит - это то, что комитет в полном составе сменился на молодых и вменяемых.
Краткое содержание: Пишу на Си. Понадобились хэши. Сам написать ниасилил. Использовать либу пе додумался. Сделал вывод что пора менять язык. Взглянул на go, rust, swift - испугался. Нашел хэши в STL. C++ - мой выбор. Малаца, хорошо сделали. (Кстати, я средний кодер и питонщик)
Сделал с for (int i = 0; i <= 99999999; i++ ) и там и там
Результат:
user@user-MS-7519:~/prog/bench$ g++ -O3 cpp.cpp
user@user-MS-7519:~/prog/bench$ time ./a.out
real 0m1.052s
user 0m0.415s
sys 0m0.620s
user@user-MS-7519:~/prog/bench$ time ./a.out
real 0m1.008s
user 0m0.407s
sys 0m0.588s
user@user-MS-7519:~/prog/bench$ gcc -std=c99 -O3 c.c
user@user-MS-7519:~/prog/bench$ time ./a.out
real 0m0.524s
user 0m0.197s
sys 0m0.316s
user@user-MS-7519:~/prog/bench$ time ./a.out
real 0m0.533s
user 0m0.203s
sys 0m0.316s
Плюсовый вектор примерно в два раза проигрывает моему наколенному велосипеду. Советую еще под strace запустить
Некогда объяснять, ты намерял фигню. Просто увеличь цикл и сравни данные с теми что ты запостил. У меня разница over 50%, у тебя комп быстрее, разница может быть ещё больше. Разбор причины оставляю в качестве самостоятельного упражнения для пытливого читателя.
По ссылке автор говорит о том что среди питона, си и цпп для больших проектов он выбирает кресты.
Не перевирай. У автора в основном питон и немножко си, в котором он ниасилил коллекции (уже фейспалм) и решил пошукать языки погламурнее. Так как все ваши горасты это вынос мозга (тут можно отчасти согласиться), остался единственный вариант: питон и кресты. И тут автор внезапно заметил няшные форы и умные указатели, теперь он фанат крестов (как мало нужно быдлокодеру для счастья).
А так не считается. Я могу и в Си предварительно malloc-нуть побольше. Тут мы сравниваем то, насколько плюсы проигрывают оттого, что приходится вместо realloc делать malloc и копировать, а потом еще free
Да речь не об этом. Я не говорю что плюсы выигрывают. Я говорю что первый твой результат ни о чём не говорит т.к. время бенчмарка сравнимо с флуктуациями.
Во втором случае мы видим что половина времени ушла в sys. В как бы _userspace_ коде. О чём это говорит? О том что у тебя на каждый чих системные вызовы идут, а это неправильно. Послушай Gvidon, он правильно указал на источник проблем.
В общем, на любом языке можно написать медленный код :( Потом, большинство программ имеют мало общего с бенчмарками, это тоже надо учитывать.
Последовательность 266240 528384 1052672 2101248 из системных вызовов mremap там такая же, как в плюсовом коде с STL последовательность вызовов mmap. Притом в плюсах каждый раз через memcpy приходится копировать данные из старой в свежеmmap-нутую память, что конечно же очень хреново с т.з. производительности
Ну и чтоб было совсем интереснее, давай аналог std::deque сделай, там поржем.
Сделаю, когда в ядре системный вызов типа mremap будет, который бы умел не только к хвосту добавлять, но и к голове.
Just as an example, I managed to write 2500 lines of C++ using the more modern style of RAII and shared pointers, and there were zero memory leaks on the first try! The equivalent functionality in C would have probably been 2x the code, and an additional week studying Valgrind errors.
Понял что конь остался в закрытом коммерц. Царь detected.
For many years I was happy as a mostly two-language programmer. Use Python for mostly everything, and drop down to C when you really need the performance. But then I started to write a medium-sized library in C that required a larger toolbox than usual.
Вот так всегда, все есть, вроде счастлив, ну не хватает чего-то и все тут...
To make a long story short, I looked into some of these languages, but eventually came back to C++.
Сказал, будто вернулся к бывшей, потому что негде больше жить :(
По теме:
Статья ни о чем. Вообще ни о чем. Сказ о том, как очередной инженер гугла «прозрел».
енивей. вектор довольно редко пользуется для такого пушинга как в примере. Чаще всего известно хотябы порядок количества элементов, ожидаемое в контейнере, поэтому делается reserve. если кто-то сильно дофига делает push, то что-то в консерватории не так.
Конструкторы копирования и деструкторы. Да, теоритически можно было бы написать специализацию вектора для чисел и указателей, но это просто никому не нужно, потому что реальной проблемы я всё равно не вижу. В подавляющем большинстве приложений никто не делает миллионы push_back'ов, а если и делает, то только после предварительного вызова reserve. Ну и накатать велосипед вроде твоего сишного тоже никто не запрещает, но это только после очень внимательного профилирования.
CoW это прежде всего оверхед, а уже потом оптимизация для отдельных случаев. Кто хочет CoW по умолчанию, то явно должен выбрать другой ЯП.
А realloc-а в std::vector НЕТУ.
Согласен, плохо. До С++11 и трейтов это было сделать невозможно, а сейчас мешают старые аллокаторы.
До сих пор НЕТУ стандартизированного ABI
И не будет. Стандартный ABI - он для примитивного С.
весь этот манглинг-деманглинг каждый может городить, как ему вздумается
Ты хотел придраться - ты придрался. А так в новомодном rust, например, тот же манглинг. В D - манглинг и т.д. Потому-что опять же это не С, где нет перегрузки функций, шаблонов, классов и т.д. и т.п.
Нормального способа работать с типами (SFINAE - костыль, и этот enable_if через SFINAE накостылен) НЕТУ.
А чем тебя enable_if не устраивает? У меня только одна претензия - многословно получается, но зато это не требовало изменения языка. К тому же clang прекрасно понимает enable_if и выдает компактные и читабельные ошибки с ним.
Метапрограммирование в плюсах сосет.
Либо у нас есть препроцессор от С, либо мы имеем нормальное метапрограммирование. У авторов С++, думаю, тоже не вызывает восторга данная ситуация.
А copy-on-write в STL НЕТУ. А realloc-а в std::vector НЕТУ. До сих пор НЕТУ стандартизированного ABI (весь этот манглинг-деманглинг каждый может городить, как ему вздумается). Нормального способа работать с типами (SFINAE - костыль, и этот enable_if через SFINAE накостылен) НЕТУ. Метапрограммирование в плюсах сосет.
Расскажи, что из вышеперечисленного лучше сделано в Си.
Надо короче лиспосишку пилить с ручным управлением памяти и удобным метапрограммированием через AST на этапе компиляции (и чтоб еще можно было и в рантайм JIT всунуть при большом желании, и там тоже метапрограммировать через AST как вздумается)
А зачем вам метапрограммирование? Можете показать пример, мол, без метапрограммирования в такой-то задаче нужно 10 приседаний, а с метапрограммированием всего 5?