ну тупыыыыые!

AGPLv3

ненужно

1. Боян
2. В предыдущем топике по этой новости обсуждали, что тесты сомнительные и нужно смотреть на практике. Плюс, вроде, обсужали, что нанять джавистов и купить железо в разы дешевле, чем нанять плюсовиков, которые бы занимались разработкой проектов похожей сложности.

Можно было бы переписать на джаве и получить то же 10-кратное ускорение. Только помимо прочего ещё и значительно сократить число buffer overflows и прочей дряни.

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

Не надо льстить плюсовикам - у них зарплата та же, что и у джавистов.

Любому приличному Программисту известно, что программы на яве такие же быстрые, как и на плюсах!

Конечно! Потому что их выполняет один и тот же Компьютер!

Зачем-то переписали DB с джавы на с++ и получили 10-кратное ускорение

Не так. Зачем-то запилили свой собственный сетевой стек, напрямую работающий с сетевой картой, свою собственную очередь обработки пакетов вместо системной и прочие довольно специфичные вещи, и после этого получили 10-кратное ускорение. Язык здесь немного вторичен.

P.S. http://www.scylladb.com/img/network.png <----- вот это

Мда, база данных с собственным сетевым стеком и прямой привязкой к драйверам сетевок карты. Воистину эталон для подражания.

+1, никто не замечает слона в комнате, ключевое слово - «переписать», или синонимы «вычистить говно» или «использовать новые алгоритмы»

Только помимо прочего ещё и значительно сократить число buffer overflows и прочей дряни.

А при чем тут C++?

При том, что в С++ легко допустить buffer overflow, расстрелять стек, чужую память и тд.

При том, что в С++ легко допустить buffer overflow, расстрелять стек, чужую память и тд.

Написать херню и отстрелить ноги себе и вон тому парню — легко на любом языке. С другой стороны, более-менее опытные кодеры c++ редко допускают озвученные тобой ошибки. В c++ самое мерзкое — это внезапные UB.

Это не совсем так, возможно в С - да, в С++ сейчас уже немного по другому все

надо подбирать железо под софт

Настолько бомбануло с фразы, что создал отдельный пост?
ЗЫ. кастую Kaschenko

Ура! Ещё один тред оправданий Java-программистов.

Крепкий сон был?

Написать херню и отстрелить ноги себе и вон тому парню — легко на любом языке.

На Java хороший вопрос для собеседования с опытным разработчиком — как расстрелять память. На C++ — как не расстрелять память. Так что нет, не легко на любом языке. Иначе все писали бы на C++ до сих пор.

С другой стороны, более-менее опытные кодеры c++ редко допускают озвученные тобой ошибки.

А часто и не надо.

На Java хороший вопрос для собеседования с опытным разработчиком — как расстрелять память.

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

Ура! Ещё один тред оправданий Java-программистов.

+1

В c++ самое мерзкое — это внезапные UB.

внезапные

ШТА?

Это не совсем так, возможно в С - да, в С++ сейчас уже немного по другому все

for (int i = 0; j < 10; i++) {
  a[i] = 0xff;
}

Что тут не так? Что поможет не испортить стек?

Настолько бомбануло с фразы, что создал отдельный пост?
ЗЫ. кастую Kaschenko

Отлично, спасибо.
ТС,
1. Баян, есть на главной
2. Это ни разу не замена оригиналу, расписано там же.
3. Фишка в сетевом стеке, а не языке
4. Так что можешь продолжать бугуртить.

Красавчик. Всегда хардкодишь размерности?

Что тут не так?

Вместо BOOST_FOREACH какая-то херня

Юноша, у вас кнопку shift судорога свела.

Они ее переписали, этим собственно всё и сказано. Видимо с++ не подходит, чтобы на нем писать что-то новое, только code monkey для переписывания.

Я уже укол кнопке сделал, кнопка теперь ок. Так где там нубы «внезапные» UB находят?

Иначе все писали бы на C++ до сих пор

Там где нужна производительность все и пишут на С/С++ до сих пор, что не так?

Да где ни попадя. https://lwn.net/Articles/342330/

При том, что в С++ легко допустить buffer overflow, расстрелять стек, чужую память и тд.

В джаве тоже есть 100500 способов выстрелить себе в ногу, это же не означает, что ими нужно пользоваться. Современный C++ позволяет вообще не думать о таких вещах, как buffer overflows, memory leaks и т.п. Поэтому все замечания подобного рода просто смешны.

По ссылке null pointer dereference в С. И? В приличных проектах принято проверять указатели перед разыменованием, чтобы не получить по морде. Получить по морде - вполне defined behavior.

Страуструп и Ко форсили другой стиль на прошедшей CppCon2015.
google: writing good c++14

https://github.com/Microsoft/GSL/blob/master/include/array_view.h
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3851.pdf

А то, что пейсатель хочет пейсать говно - не проблема языка.

В приличных проектах принято

Вообще-то по ссылке речь идёт об относительно приличном проекте.

Соседний тред тонко намекает. Хотя кресты тоже сомнительной нужности язык.

Какой-то странный вопрос. Во-первых, кто сказал, что именно стек? Во-вторых, в большинстве случаев сейчас используется range-based for loop (как и в джаве). В-третьих, используются специальные контейнеры вроде std::vector и std::array итерация по которым осуществляется с помощью итераторов. В-четвертых, вот была недавно тема: Опубликованы C++ Core Guidelines array_view - как раз про это. Так что C++ это действительно не C с классами, как многие продолжают думать.

у них зарплата та же, что и у джавистов.

только скорость выполнения проектов не фонтан ))

только скорость выполнения проектов не фонтан ))

Выполнения - как раз фонтан. А вот написания...

AGPLv3

ненужно

Почему бы? Граница лицензии проходит по границе процесса, поэтому тут сравнительно пофиг, пока не начинаешь патчить саму эту поделку.

чужую память

Чужую - это какую?

написания, да.

Это тот самый печально известный подвид C++ программиста, работающего через «C с классами»?

Что поможет тебе не получить @NullPointerException в Java?

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

Какой-то странный вопрос. Во-первых, кто сказал, что именно стек?

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

Во-вторых, в большинстве случаев сейчас используется range-based for loop (как и в джаве).

А в меньшинстве используется индексированный доступ, как и в джаве. Даже в хорошем коде. А хороший код не везде.

В-третьих, используются специальные контейнеры вроде std::vector и std::array итерация по которым осуществляется с помощью итераторов.

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

В-четвертых, вот была недавно тема: Опубликованы C++ Core Guidelines array_view - как раз про это. Так что C++ это действительно не C с классами, как многие продолжают думать.

С++ это C с классами и шаблонами. То, что энтузиасты (мизерная доля от всех программистов на С++) пытаются на этом слепить безопасное подмножество языка, никуда не девает всё остальное (и всех остальных). Rust это не C с классами, это да. Тут соглашусь. А C++ это именно, что C с классами.

Exception полностью безопасен и ничего не портит

Джуниор детектед.

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

for (int i = 0; j < 10; i++) {
a = 0xff;
}

Вижу С, не вижу C++.

... А at никто не пишет. ...

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

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

Кстати, в отличие от чего?

В отличие от одного процесса.

В таком случае C не страшны segfaults - родительский процесс просто залоггирует ошибку и запустит новый.

А с чего ты взял, что будет segfault? Это я примитивный пример привёл. В реальной жизни всё бывает куда сложнее. Попортили переменную выше по стеку. Вернулись, вернули клиенту неверный ответ. И дальше работаем. Отлавливать такую ошибку — врагу не пожелаешь.