C++/Qt, удаленка, part-time

>Исключения - это прежде всего возможность сообщить коду наверху о наличии ошибки и корректно свернуть стек. У них одно важное преимущество (при соблюдении некоторых условий) - промежуточный код может и не знать о возможности ошибки.

Разницу между кодером и программистом знаешь? Кодер знает, как писать код, а программист знает как правильно писать код. Вот Страуструп и пишет, как правильно писать код, что для чего предназначено и что чем не является, хотя это многие и предполагают. Надеюсь ты не считаешь себя уровнем выше Страуструпа? Тебе дали номер главы - 14.5, там всего несколько предложений, может осилишь?))

Банальный пример: пользователь вводит данные в поле. Нажимает enter. Летит exception, что данные пользователя неверны. Этот exception ловится в цикле обработки сообщений и показывается пользователю. Все красиво и корректно

Ипать, теперь я понял почему от вас ушли через неделю два новых программиста. Вопрос, а гвозди микроскопом забивать у вас тоже практикуется?))) Стёб стёбом, но тебе или в Java идти или читать Страуструпа.

Хм. Я тогда был маленький и глупый, а это решение я почерпнул из опыта работы в ABBYY. Я конечно понимаю, что программсты в ABBYY плохие, архитектура ужасная, и тд. И понимаю, что исключения использовать не надо - лучше в каждом месте нагородить тонну кода для сигнализирования пользователю, а так же еще и связаться модули, чтоб внутренний модуль знал о существовании GUI и знал, как сообщить оттуда, что произошла ошибка. Уж не говоря о механизме прекращения обработки текущей задачи, который должен пронизывать все функции.

ты и сейчас не умнее

>Я тогда был маленький и глупый

Не стоит оправдываться.

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

Архитектура там вообще трындец, как-то пришлось работать с форматом словаря ABBYY, парсить его. Очевидно, что формат словаря ABBYY был придуман ещё до того, как эти программисты узнали про реляционную модель хранения данных и системы управления ими.

И понимаю, что исключения использовать не надо - лучше в каждом месте нагородить тонну кода для сигнализирования пользователю

Для начала может посмотришь накладные расходы на генерацию одного исключения? Они в сто и более раз больше, чем просто вернуть признать истина/ложь. Про валидаторы ты тоже ничего не слышал? Как же ты тогда на Qt пишешь...

а так же еще и связаться модули, чтоб внутренний модуль знал о существовании GUI и знал, как сообщить оттуда, что произошла ошибка

Т.е. ты из модуля в модуль гоняешь исключения? Мдя, это трындец.

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

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

еще один

если есть С++, если есть его возможности - то ими надо пользоваться. А не думать о том, что это кому-то не нравится

> Для начала может посмотришь накладные расходы на генерацию одного исключения? Они в сто и более раз больше, чем просто вернуть признать истина/ложь.

оно прям выбрасывается 100000 раз в секунда. С какой же скорость пользователь кликает?

Т.е. ты из модуля в модуль гоняешь исключения? Мдя, это трындец.

Если этот модуль работает только с этой программой, то в чем проблемы?

А флаг использовать не судьба?

И потом в каждом месте проверять флаг - а не упали ли мы.

void f() {
call_smth();
if( fail )
return;
call_smth2();
if( fail )
return;
}

void f1() {
f();
if( fail )
return;
}

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

Может. Поэтому код и должен быть готов прерваться. Или обработать свое прерывание.

много поточный код должен сам корректно тормозиться

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

>если есть С++, если есть его возможности - то ими надо пользоваться. А не думать о том, что это кому-то не нравится

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

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

да тупой он

>оно прям выбрасывается 100000 раз в секунда. С какой же скорость пользователь кликает?

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

Если этот модуль работает только с этой программой, то в чем проблемы?

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

Может. Поэтому код и должен быть готов прерваться. Или обработать свое прерывание.

Код должен проверят флаг не просят ли его прерваться и только. Всё остальное ведёт к некорректному состоянию при принудительном завершении.

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

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

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

Вот когда ты поймёшь когда целесообразно, а когда нет использовать те или иные возможности тогда ты из кодеров перейдёшь в программисты.

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

Можно всю жизнь сидеть и использовать только часть возможностей.

Исключение - это не только критические ошибки. Исключение - это состояние, когда выполнение кода не может быть продолжено. И, когда такое поведение, не является нормой.

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

>Можно всю жизнь сидеть и использовать только часть возможностей.

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

Исключение - это не только критические ошибки. Исключение - это состояние, когда выполнение кода не может быть продолжено. И, когда такое поведение, не является нормой.

Ещё раз - Страуструп, глава 14.5. Исключения это способ прыгнуть из места генерации исключения в место его перехвата с раскруткой стека. И всё. Использование исключений в качестве механизма обработки ошибок это только одно из возможных применений и единственное только в том случае если человек настолько туп что не может осилить Страуструпа.

Не фига себе способ с накладными расходами...

Приведите пример другого использования.

>я не вижу дальше возможности спорить с человеком, который предпочитает отговариваться фразами, которые сам до конца не понимает

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

>Не фига себе способ с накладными расходами...

Приведите пример другого использования.

Этого мало? Кругозор у тебя небольшой... Realtime, embedded. Ещё?

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

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

> Этого мало? Кругозор у тебя небольшой... Realtime, embedded. Ещё?

как это связанно с искчлючениями?

ты сам как исключение

>То, что исключение позволяет тебе передать управление выше по стеку не означает, что этим надо пользоваться.

Для тебя Страуструп не авторитет, считаешь себя в праве его оспаривать, корректировать? Если Страуструп сказал, что исключения как способ обработки ошибок используется только потому, что так все привыкли думать и это не значит, что это единственное и целевое применение.

>как это связанно с искчлючениями?

Сколько тебе вообще лет? Тебя из ABBYY выперли или сам ушёл?

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

В embedded исключения не применимы по причине ограниченности ОЗУ.

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

Страуструп привел 2 сомниетльных места для использования исключения.

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

Да, и он сказал, что это почти не где не оправдано.

> В realtime накладные расходы на генерацию исключения непозволительная роскошь, они там в принципе не применимы.

Ты на какой вопрос то отвечаешь?

>>>> Этого мало? Кругозор у тебя небольшой... Realtime, embedded. Ещё?

как это связанно с искчлючениями?

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

Ты на какой вопрос то отвечаешь?

Догадаешься или пальцем показать?

Покажу уж я:

Ещё раз - Страуструп, глава 14.5. Исключения это способ прыгнуть из места генерации исключения в место его перехвата с раскруткой стека.

И как это к embedded относится?

>Да, и он сказал, что это почти не где не оправдано.

Нужно понимать почему не оправдано, если у тебя каждая функция, функция член может кинут исключение твоя программа скатится в унылое говно. Даже сама структура:

try {} catch (exeption) {}

Вызывает генерацию лишнего нативного кода, а это непопадание в кэш, более медленная работа ПО, более агрессивное потребление памяти и т.д.

Так это и недостаток. Лишний раз перехват исключения - это нагрузка даже на нормальный поток исполнения

>Покажу уж я:

Ещё раз - Страуструп, глава 14.5. Исключения это способ прыгнуть из места генерации исключения в место его перехвата с раскруткой стека.

И как это к embedded относится?

С realtime не прокатило решил embedded оспорить?)))

У тебя исключение, что собой представляет объект который занимает память или эфемерную без телесную материю? Если объект то сам подумай, если в embedded ограничение на используемое ОЗУ? Есть ли в embedded ограничение на размер исполняемого кода или код можно бесконечно раздувать с помощью try {} catch() {}? Есть ли в embedded ограничение на производительность проца?

>Так это и недостаток. Лишний раз перехват исключения - это нагрузка даже на нормальный поток исполнения

Т.е. ты всё ещё не допёр, что механизм исключений даже для обработки ошибок тормозит код даже если сами исключения не генерируются?

Господи. Ну куда делись мозги у анониму. Вроде умные вещи пишет, а проследить мысль не может.

Я попросил тебя привести примеры, когда стоит использовать исключение для передачи управления. Та написал: realtime, embedded

Так яснее?

> Т.е. ты всё ещё не допёр, что механизм исключений даже для обработки ошибок тормозит код даже если сами исключения не генерируются?

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

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

Может для начала научимся писать последовательно?

>>Т.е. ты всё ещё не допёр, что механизм исключений даже для обработки ошибок тормозит код даже если сами исключения не генерируются?

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

Не тупи, даже если ты исключения не генерируешь код для try catch всё равно компилятор генерирует, а это уже накладные расходы от которых не уйти на то, чем ты может и не будет пользоваться в работе ПО или раз в месяц столкнёшься с исключением.

А если у тебя исключения валятся постоянно тебя нужно гнать сс#ными тряпками с работы.

>Может для начала научимся писать последовательно?

Рано, начни с Букваря.

> Не тупи, даже если ты исключения не генерируешь код для try catch всё равно компилятор генерирует, а это уже накладные расходы от которых не уйти на то, чем ты может и не будет пользоваться в работе ПО или раз в месяц столкнёшься с исключением.

Если у тебя есть проверка флага/возращаемого значения, то это тоже дополнительный код - значит расходы. Так?

>Если у тебя есть проверка флага/возращаемого значения, то это тоже дополнительный код - значит расходы. Так?

Нет, не так, проверка флага одна ассемлерная команда - JZ и т.п., а это ничто по сравнения с тем, что генерирует компилятор для try/catch.

>Нет, не так, проверка флага одна ассемлерная команда - JZ и т.п., а это ничто по сравнения с тем, что генерирует компилятор для try/catch.

Причём можно принудительно указать наиболее вероятный вариант ветвления с помощью likely() и избежать ветвления. Держу пари, что ты не знаешь, что при каждом ветвлении кэш помечается, как недействительный и процы с большим конвеером в этом месте тормозят пока загружают новый код.

> Нет, не так, проверка флага одна ассемлерная команда - JZ и т.п., а это ничто по сравнения с тем, что генерирует компилятор для try/catch.

А я не буду вставлять try/catch. Зачем мне перехватывать исключение, если я его не собираюсь тут обрабатывать. Пусть летит дальше

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

Не при каждом, а только при промохе

>А я не буду вставлять try/catch. Зачем мне перехватывать исключение, если я его не собираюсь тут обрабатывать. Пусть летит дальше

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

>Не при каждом, а только при промохе

Во первых при каждом т.к. спекулятивное построение предсказаний это особенности конкретных процессоров, их внутренней реализации. Появилось оно кажется в Penryn, но ему это не помогло в виду большого конвеера. А есть ли такая штука на АМД не известно.

> Т.е. исключение нигде не будет перехватываться, а сразу завершать программу через terminate()?

Перехватчиков должно быть минимальное число

>Перехватчиков должно быть минимальное число

Т.е. куча функций кидает исключения, как ты сам писал на странице №1, а перехватчиков только несколько. Как всё запущено, иди читай Страуструпа - исключение должно перехватываться на там уровне где достаточно информации для его обработки. Ты реально не понимаешь сути.

блин. я даже не знаю, что ответить...

разговор с глухим

>разговор с глухим

просто ты тупой и этим всё объясняется.

Да кто бы спорил. В вашем мире видать много тупых.

Но пора вернуться в реальность :) Хотя нам без вас не плохо живется

>Хотя нам без вас не плохо живется

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

К вам ушли?