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

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

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

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

1. В сраной жабке нет raii, так смотри не обосрись с finally-блоками. Протечёшь.
2. Даже если бы жабку починили и у вас был бы адекватный аналог деструкторов, это не решило бы проблем с потерей логической консистентности композитов.

1. В сраной жабке нет raii, так смотри не обосрись с finally-блоками. Протечёшь.

Утечка это наверное самый безобидный из всех багов.

2. Даже если бы жабку починили и у вас был бы адекватный аналог деструкторов, это не решило бы проблем с потерей логической консистентности композитов.

Нет таких проблем.

Утечка это наверное самый безобидный из всех багов.

Лол.

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

Нет таких проблем.

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

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

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

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

Подгрузить модуль на JNI, который расстреливает память?

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

Это уже неважно. NullPointerException означает кривой код.

Это же ложь! Плюсовики стоят нынче дешевле джавистов.

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

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

У них да, а у их шефа?

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

Ты, конечно же, слышал про levels of exception safety? Давай разберем гарантии, которые программист обязан обеспечить для самого слабого уровня, basic exception safety: "Partial execution of failed operations can cause side effects, but all invariants are preserved and no resources are leaked. Any stored data will contain valid values". Обрати внимание, сколько тут слов. Гарантии "no resources are leaked" тебе в случае жабки даст сборщик мусора + наивная расстановка finally-блоков, в случае крестов даст наивное использование raii. А вот как быть с остальными словами в формулировке? Вот с этим: "all invariants are preserved"? Вот с этим: "any stored data will contain valid values"? Это всё на совести кодера, и при мало-мальски сложной структуре данных написать exception-safe код становится нетривиальной задачей.

Примеры? Красивых примеров сходу не нагуглилось. Составлять и разжевывать такой пример здесь на форуме — мне лень. Но чтобы ты мог почувствовать вкус проблемы, могу привести пример вот отсюда:

http://www.gotw.ca/publications/mill12.htm

To begin, consider an exception safety challenge proposed by Tom Cargill:

  //  Example 1: The Cargill Widget Example
  //
  class Widget
  {
    Widget& operator=( const Widget& ); // ???
    // ...
  private:
    T1 t1_;
    T2 t2_;
  };

Assume that any T1 or T2 operation might throw.

In Example 1, it's not possible to write a safe Widget::operator=() at all — we cannot guarantee the Widget object will even be in a consistent final state if an exception is thrown, because there's no way that we can change the state of both of the t1_ and t2_ members atomically.

Зачем, если есть

for(auto&& element: array)

поди к поделке еще какая-то клиентская часть идет (драйвер ODBC/JDBC/???), и она тоже под AGPL, и линковаться с ней уже зашквар..

Для C++03

Проще через класс Unsafe.

Это уже неважно. NullPointerException означает кривой код.

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

Вот именно. Плюсовики сами себе придумали проблему и сами её мужественно пытаются решить. Даже если ты не закрыл файл через finally, его достаточно быстро закроет GC и на системе скорее всего это никак не отразится. В отличие от C++, где этот файл не будет закрыт до конца работы программы (и не дай бог, программа грохнется с коре дампом, прощайте stdio-шные буферы).

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

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

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

И? В одном случае кривой код портит пользователю данные и пользователь несёт многомиллионные убытки.

В первом случае это твои фантазии. Ты это представляешь так, будто выход за границы массива (да ещё и на стеке) - это какая-то очень распространенная и труднообноруживаемая проблема. На самом деле это не так. И тебе уже устали все объяснять, что работа с памятью в современном C++ - это вообще не проблема, это даже проще, чем в Java - по крайней мере не нужно думать как бороться с тормозами от GC. Есть куда более насущные проблемы вроде многопоточности. Но и тут у джавы преимуществ нет (ключевое слово synchronized - такая-же наивная попытка изобрести серебряную пулю, как и GC).

Вообще-то, разумно.

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

заменив его на nullpointer exception?

то есть, вы даже не в курсе, как в плюсах циклы пишутся? ок.

for(auto &i: a)
 i = 0xff;

просвещайтесь.

Мне нужно заполнить первые 10 элементов, а не весь массив.

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

Даже если драйвера нет и ты сам реализуешь протокол, то тоже поимеешь геморрой. В серьезных конторах AGPL софт не подпускают на пушечный выстрел.

база данных с собственным сетевым стеком и прямой привязкой к драйверам сетевок карты.

они же dpdk используют, это не совсем велосипед.

на dpdk ещё любят DOS всякие делать

dpdk.org

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

Может быть потому что на жаве не нафигачь кастомный сетевой стек и прочие железячные примочки?

В серьёзных конторах не страдают фигнёй вроде хейтерства AGPL.

сразу видно знатока серьезных контор ))

Если AGPL-софт не находится в одном адресном пространстве с твоим и ты юзаешь его API, совместимое с API чего-либо ещё (например, apache cassandra), то твой софт не является производной работой и единственное ограничение на тебе — в том, что ты не можешь распространять свой не-AGPL софт вместе с AGPL-зависимостью.

Ну так сделай итератор, который идет либо до 10, либо (если конец раньше) до конца.

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

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

В одном случае <...> пользователь несёт многомиллионные убытки

В другом случае <...> не работает какая-то редкая функциональность

Хехехе)

ога

Мне нужно заполнить первые 10 элементов, а не весь массив.

Prelude> let xs = [1..20]
Prelude> xs
[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20]
Prelude> [100..110] ++ drop 10 xs
[100,101,102,103,104,105,106,107,108,109,110,11,12,13,14,15,16,17,18,19,20]

Циклы, итераторы, ещё какая-то срань. Зачем это всё?

а тут говорят, что джава не тормозит

Странно, что никто не заметил: индекс — переменная i, а в условии — переменная j. Хотя, конечно, это не идиоматичный код в современном C++, а потому ССЗБ.