Почему исключения в С++ считаются медленными?

Плохой пример - не знаю машин с электроникой в тормозах - никто такделать не будет.

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

А кто в реалтаймовых задачах использует исключения?

не знаю машин с электроникой в тормозах - никто такделать не будет

Пора сменить ВАЗ 2101 на машину, узнаешь много нового.

У меня Toyota Corola :)

проходя прослойку от ядра/иксов/glib/стандартной библиотеки/библиотек IO/...путь до твоего кода...

Я не знаю, о чем это, но точно не об исключениях С++ реализованных по Itanium ABI. Ядро никакого участия в С++-исключениях не принимает, и «прохождение пути по бибилотекам и пр.» сводится к банальной раскрутке стека, которой глубоко фиолетово на «пределы одного бинарника»

Хотя может в этих ваших шиндошс все по-другому

которой глубоко фиолетово на «пределы одного бинарника»

вызов функций и проверка условий-глубоко фиолетово акей

раскрутка стека есть только в бинарных библиотеках,более того которые СПРОЕКТИРОВАНЫ с исключениями которые работают в пределах своего кода(без вызова тыщ других функций из условий)

но реальность такова-ожидая file IO error/exception стандартная библиотека с++(от гцц) полезет в ожидание ф/ио состояния от ядра,а в ядре нынче всякие FUSE или драйвер «новомодных» ФС(типа бтрфс)-и они скриптовые,тоесть ожидание выполнение скриптового сценария транслятором для обработки исключения(ибо read write операции сквозные и пиши хоть на питоне,а вот выполнение условий скриптовых...время)

и это в том случае если у тебя программа таки использует именно метод read/write стандартной библиотеки-что врятли возможно,99% программ пишутся на всяких кутях,гтк,виксвиджетс...в которых свои функции ввода/вывода,и которые-ВНЕЗАПНО завязаны на скриптовые элементы ДЕ/движка(тоже исключение файл запись чтение-пройдет длиннющий путь(ага ибо наши любимые библиотеки все еще не многопоточны и при исключении-оно отдастся сначала более «важным»/высоким уровням движка и только в конце после проверки критичности исключения-оно отдастся твоему коду))

и это я про простейшую запись файла-про кошмар в исключении «объекта UI»,или исключение инициализации устройств-там пути обтекают ядро иксы весь юзерспейс десктопных библиотек,с ожиданиями ответов от скриптов питона...

так о каких исключениях ты говоришь,о реальности или о 90-х годах?

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

Конечно эту муть про ядра и иксы я ваще не распарсить и к чему ты её выдал - не представляю, наверное в жабке иксов и ядра нет, но это экспертам всётаки виднее.

также медленно,если учитывать что if самая медленная операция для ЦП

Датычё, правдачтоли? А пацаны-то не знали, а рандомный балабол на лоре срывает покровы.

в JIT-прелоадинг и прекомпайлинг плюс шаблоны сценариев-ускоряют исключения до скорости case/switch в томже движке

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

Ну чтож ты так яро срываешь покровы.

что быстрее if/else в томже движке,но в разы медленее нативных компиляторов

А, дак в условный переход в движке софтварный? И жит типа не нативный конпелятор?

Он конпелирует в ненативный поникод, который исполняет свой радужный процессор через либастрал?

где рандомный переход лучше условного константного.

Где ты вообще такое видел? И вообще, что по-своему делает этот твой «рандомный переход», как он работает?

У fuse сишный апи как и ядра. А ждать искличение из сишной фии это как бы ждать поезд на автобусной остановке, те шиза, в чистом виде. Я как бы хочу сказать, что если ты болен шизофренией, то да - это проблема. Но в этом случае дело не в эксепшонах.

но реальность такова-ожидая file IO error/exception стандартная библиотека с++

Ожидая, наверное через либастрал ей радужный процессор отправит?

полезет в ожидание ф/ио состояния от ядра

А, подожди. А как она полезет, если ексепшена ещё не было? Как она о нём узнает, чтобы полезть?

Т.е. она лезет в состояние ядра каждый раз?

в ядре нынче всякие FUSE или драйвер «новомодных» ФС(типа бтрфс)-и они скриптовые,тоесть ожидание выполнение скриптового сценария транслятором для обработки исключения(ибо read write операции сквозные и пиши хоть на питоне,а вот выполнение условий скриптовых...время)

Что? Какого сценария, зачем его ожидать?

99% программ пишутся на всяких кутях,гтк,виксвиджетс...в которых свои функции ввода/вывода,и которые-ВНЕЗАПНО завязаны на скриптовые элементы ДЕ/движка

ексепшены - кути, да пацан явный эсперт.

Элементы ДЕ + io - это так мило, пацан явный эсперт.

Я так и не понял - в жабке разве нативные риды юзаются, либо тоже обёртки?

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

так о каких исключениях ты говоришь,о реальности или о 90-х годах?

Я не знаю о чем говорит он, но я знаю о чем говоришь ты - о мире пони, желания о котором говорить - вызванные тотальным анскиллом.

Где ты вообще такое видел?

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

И вообще, что по-своему делает этот твой «рандомный переход», как он работает?

Загугли.

царь, что быстрее в плюсах,

struct Counter
{
  virtual void inc() = 0;
  virtual int value() = 0;
};

struct Count1: Counter
{
  Count1() : c0(0) {}
  int c0;
  void inc() {++c0;}
  int value() {return c0;}
};

int main()
{
  Count1 c0;
  Count1 c1;
  Counter *c[2] = {&c0, &c1};
  for (i = 0 to over9000) {
    j = rand_from_zero_to_one();
    c[j]->inc();
  }
  printf("zeros: %d, ones: %d\n", c[0]->value, c[1]->value);
}

int main()
{
  int zeros =0;
  int ones = 0;
  for (i=0; to over9000) {
    j = rand_from_zero_to_one();
    switch (j) {
      0: ++zeros;break;
      1: ++ones; break;
    }
  }
  printf("zeros: %d, ones: %d\n", zeros, ones);
}

быстрее в плюсах

gcc 5.1 с lto выкинет виртуальный вызов и разницы может не быть вовсе.

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

c[j]->inc();//это инлайн, хотя гцц может не осилить - шланг должен осилить.
++c[j];

switch (j) {
      0: ++zeros;break;
      1: ++ones; break;
    }
Ну тут тоже самое.

rand_from_zero_to_one не учитываем. считаем, что оно 0 ns.

Так не бывает.

Ну если осилит инлайн - будет тоже самое, а не осилит будет не тоже самое.

А вообще пацан пишет так:

for (i=0; to over9000/8) {
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
    j = rand_from_zero_to_one();
    zeros += (j == 0), ones += (j == 1);
  }

Сходи забенчи - расскажешь.

Да тут уже не трава, а что-то потяжелее