ну и как ты думаешь, нужны нам все 500к строк? или работающего примера хватит?

сделает хуевый велосипед и успокоится

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

Кстати, ты же ассемблерный код читаешь. Расскажи, switch за О(1) или за О(N) находит нужный case. https://godbolt.org/g/h7pnAK

там же строится jump table

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

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

это в if ищется дольше

там же строится jump table

Какая разница? Условия-то надо всё равно все перебрать.

В худшем случае.

это в if ищется дольше

Я читал про это, но решил проверить

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

А что там? В чем принципиальная разница между "функция вернет значение или бросит исключение" и "функция вернет сложный объект как значение"?

cmp eax, 91 je .L3 cmp eax, 91 jg .L4 cmp eax, -1 je .L5 cmp eax, 3 je .L6 jmp .L2 вот твой свитч - иф-джамп-иф-джамп

То есть О(N)?

Какая разница? Условия-то надо всё равно все перебрать.

так, внимание вопрос: а зачем тогда switch нужен?

Да.

Какая разница? Условия-то надо всё равно все перебрать.

нет, немного не так как в ифах, свитч быстрей (как асемблерщик говорю)

cmp eax, -1 je .L5 cmp eax, 3 je .L6 jmp .L2 .L4: cmp eax, 69199 je .L7 cmp eax, 1255125 je .L8 jmp .L2 он еще смешно поделил пополам по значению 91

так, внимание вопрос: а зачем тогда switch нужен?

Низачем. Это просто конструкция языка. Все равно будет n проверок для n-ного кейса.

cmp eax, 91 je .L3 cmp eax, 91 jg .L4 cmp eax, -1 je .L5 cmp eax, 3 je .L6 jmp .L2 вот твой свитч - иф-джамп-иф-джамп

зависит от компилятора :D

Может он как хеш таблица работает?

Низачем. Это просто конструкция языка. Все равно будет n проверок для n-ного кейса.

Нет

Тогда О(1)

нет, немного не так как в ифах, свитч быстрей (как асемблерщик говорю)

Конечно не так, но вопрос-то был про асимптотику.

зависит от компилятора :D

ну естественно, и от опций компиляции

O(log N) показывает Беркус

что-то я раньше читал, что switch шустрее должне быть. Но за ассемблер не могу ничего сказать

O(log N) показывает Беркус

вот в это верю

Я всегда проверяю -О0

O(log N) показывает Беркус

да, близко к тому

ну очевидно что компилятор пока строит дерево поиска

O(log N) показывает Беркус

Это легко ломается же.

видимо, для 100 значений он будет вычислять переход, но это не точно

Сделайте порядок в switch-e другой и break уберите.

Я всегда проверяю -О0

а зачем ты так делаешь?))

И ему ничего не останется как сделать честные O(n) проверок.

а зачем ты так делаешь?))

Так интереснее

cmp esi, 91 je .L3 jg .L4 -Ofast сделал немного peephole оптимизаций убрав релоады

что-то я раньше читал, что switch шустрее должне быть. Но за ассемблер не могу ничего сказать

зависит от компилятора(и флагов как подсказали). jump table быстрей чем if, но если просто сравнение - то тоже самое по сути

https://stackoverflow.com/questions/1837656/jump-table-switch-case-question

но в целом история та же

Логарифм там только для break в каждом кейсе. Тогда действительно, поскольку свитч только для целых на которых есть сравнение.

Кстати, Беркус, а как в случае возврата Result<T, Error> глобально переопределить действие при ошибке?

зависит от компилятора(и флагов как подсказали). jump table быстрей чем if, но если просто сравнение - то тоже самое по сути

jump table быстрее ЕСЛИ верно хотя бы одно из a) все значения идут подряд b) их много

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

Jump table не то чтобы обязательно быстрее. Поход в память штука дорогая.

Я проверял на ICC, clang, GCC они без оптимизаций примерно одинаковый код дают

Кстати, Беркус, а как в случае возврата Result<T, Error> глобально переопределить действие при ошибке?

глобально задавай handler для unwrap()

Сравнение работает быстрее.

.unwrap() => { if (err) handler(); return T; } handler() = panic();

jump table быстрее ЕСЛИ верно хотя бы одно из a) все значения идут подряд b) их много

кстати да, много и подряд то что нужно ?

глобально задавай handler для unwrap()

template <...> global_unwrap_handler()

глобально задавай handler для unwrap()

Это теперь чат про rust?

Это теперь чат про rust?

нет, перетаскиваем best practices

Короче, скажите да. Switch в худшем случае работает за О(N)

Да.

Я не спорю что вся механика Result<> очень хороша при наличии do-нотации и если надо заставлять проверять ошибки, это просто совершенно не тот случай

Здесь скорее нужен variant<enum, callback> как параметр

ну оно и без do-нотации зачудительно работает

нет, перетаскиваем best practices

А паттерн матчинг уже завезли в C++?

А паттерн матчинг уже завезли в C++?

да, конечно

очень частично

А паттерн матчинг уже завезли в C++?

да-да, уже есть. Вместе с рефлексией можешь юзать

да, конечно

Это мне по нраву

А паттерн матчинг уже завезли в C++?

https://github.com/mpark/patterns

#import <pattern_matching>

#import <pattern_matching>

в примерах написано #include <mpark/match.hpp>

в примерах написано #include <mpark/match.hpp>

дык это левый какой-то паттерн-матчинг. Я тебе говорю про стандартный ?

так тебе шашечки или ехать?

#import <pattern_matching>

должно быть в модуле

ERROR: S client not available

#import <pattern_matching>

И модули уже завезли? Я просто был в спячке тут долгое время

И модули уже завезли? Я просто был в спячке тут долгое время

эххх, ничего ещё не завезли....

И модули уже завезли? Я просто был в спячке тут долгое время

http://ideone.com/BnktIj

))

Вопрос: У меня есть кастомное исключение, которое принимает кастомный enum class ErrorCode, хранит в себе unordered_map<ErrorCode, string/*Строка с описанием проблемы*/>. При вызове what() возвращаеься строка с описанием соответствующей проблемы.

Теперь мне нужно чтобы в строке было еще и текущее состояние объекта. Ну там, типа "Network interface" + networkInterface.to_string() + is not supported";

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

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

А, вопрос

Почему я так ублюдочно это все делаю и как лучше?

конструируй исключение с нужной тебе инфой

а потом внутри what() выводи в нужном тебе виде

Просто тогда я во многих местах буду дублировать код, пишучи throw myException("Описание проблемы на 100500 строк" + currentValue1 + "Еще 100500 строк" + currentValue2); И я бы хотел чтобы логика конструирования строки была внутри самого what() Плюс мне надо в эксепшене хранить ретурнкод с которым программа должна завершиться

А он как раз определяет какое сообщение об ошибке

Просто тогда я во многих местах буду дублировать код, пишучи throw myException("Описание проблемы на 100500 строк" + currentValue1 + "Еще 100500 строк" + currentValue2); И я бы хотел чтобы логика конструирования строки была внутри самого what() Плюс мне надо в эксепшене хранить ретурнкод с которым программа должна завершиться

Зачем? основную инфу держи в своей мапе

а вспомогательную передавай. Потом скомбинируй в нужном порядке внутри what()

или тебе такое тоже не нравится?

Просто тогда я во многих местах буду дублировать код, пишучи throw myException("Описание проблемы на 100500 строк" + currentValue1 + "Еще 100500 строк" + currentValue2); И я бы хотел чтобы логика конструирования строки была внутри самого what() Плюс мне надо в эксепшене хранить ретурнкод с которым программа должна завершиться

логика коструирования строки как раз таки и будет внутри what ?

ты понял, что я тебе предлагаю?

Да, допер

Спс

Да, допер

?

хм... а что если я буду вместо коллбека передавать что-то такое template <typename DefaultOptionsType, /*сигнатура функции*/> struct customizable_dispatcher { //конструкторы в стиле variant<DefaultOptionsType, function</*сигнатура функции*/>> /*возврат из сигнатуры функции*/ operator ()(function</*сигнатура функции плюс параметр DefaultOption*/> defaultCallback, /*параметры из сигнатуры функции*/){ //проверить variant и либо вызвать функцию, либо defaultCallback с соответствующей опцией } };

хм... наверное даже не function(/**/) а просто указатель на функцию, потому что параметров принципиально должно быть достаточно

Делай так, чтобы было неважно, что пользователь передаст: функцию, функтор, лямбду или std::function

тебя же только волнует, чтобы у этой сущности был ()

Вроде как в 99% случаев создание объекта потеря времени

Речь о поведении при ошибке по умолчанию, user-defined option разумеется <s>всегда лямбда</s> function

Вроде как в 99% случаев создание объекта потеря времени

это уже пользователю функции решать

что за велосипед на этот раз я изобрел?)

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

потому что в этом случае я не смогу написать унифицированную версию throw_exception