стандартная реализация std::string

в куче, как и у исключений.

На многих платформах просто try\catch не бесплатный, а throw вообще дороженный.

Я правильно понял паттерн, что функтор возвращается вместо обычного типа?

Ты хаскелль знаешь?

Нет, к сожалению, но понимаю концепт

Можно рассматривать и как фунцтор в каком-то отадленном приближении. Но вообще возвращается Either

Возвращается объект — алегбраическое произведение типов.

Либо то, либо тш

Так мы про хаскель или плюсы?

Т.е. штука, у которой можно взять либо значение, либо ошибку, и флажок, который говорит что там лежит.

Про Expected<T>

Плюсы.

Надо почитать

Да, обычный union + placement new

Плейсмент на стеке, соотв?

Ибо если там хип юзают на каждый объект - труба дело

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

Да, обычный union + placement new

С языка снял

Ничем не отличается от обычного вызова функций. Значения куда клались — туда и кладутся. И RVO работает.

Только это RVO еще и для ошибок тоже.

Можно спокойно сделать тип ошибки какой-нибудь uint32_t и тогда вообще throw по стоимости return получается.

Ибо если там хип юзают на каждый объект - труба дело

любой throw использует кучу, и гораздо хуже чем ты думаешь :D

любой throw использует кучу, и гораздо хуже чем ты думаешь :D

Try не юзает кучу когда нет эксепшн. Вот я и спрашиваю как с этим дела у эксептед

Никак. Зиро оверхед.

И try-таки кое-что юзает. Это сильно платформ спесифик.

Не может быть зиро, на каждый возврат + байт, который надо заинитить

Для больших x86 может и не юзает. Для других платформ хуже.

Я имел в виду по инструкциям.

По памяти да, на один байт на стеке больше.

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

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

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

Согласен.А вот интересно, этот байт выровненный? Как у него дела при доступе к памяти на машинах, которые умеют только aligned доступ?

Во-первых в языке есть alignas

Т.е. Если я верну просто инт - все хорошо, а эксептед?

А во вторых байт кладется после значения, поэтому он выровнен так же как return type

В качестве возвращаемого значения используется pod, по размеру равный 1byte+ max(sizeof(ReturnType), sizeof(ErrorType))

Тогда конфликтует с этим

Ну да-да, я имел в виду после значения ошибки или результат :D

Понятно.

В общем, надо на практике посмотреть. А идея хороша

Просто каждый раз это уточнять поленился.

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

Но у него было странное решение заворачивать экспешны в качестве ошибок

И не было байндера

Но меня вполне бы устроило так, как описано в пропозале.

Но меня вполне бы устроило так, как описано в пропозале.

Скинь линк

Бтв, в таком языке как rust "исключительные" ситуации обрабатываются именно так.

https://isocpp.org/files/papers/n4015.pdf

Спс

Вртде ты скидывал, не заметил

Угу. А когда в компиляторы войдет http://en.cppreference.com/w/cpp/experimental/optional/in_place_t вообще будет можно сделать еще и реализацию очень красивую.

Вообще, эксептед , фактически, это расширение подхода return codes?

Не сказал бы. Для вызывающего кода это не выглядит так.

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

Разве там генерится исключение при ошибке?

Где?

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

Ты ответил

Угу.

Надо разворачивать монаду

Просто нельзя взять и использовать ретёрн тайп напрямую.

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

Тогда вот контр-аргумент похода https://isocpp.org/wiki/faq/exceptions#exceptions-avoid-spreading-out-error-logic

Я успел раньше написать ответ на это контраргумент :3

И пара ответов ниже в том же факе.

Тогда вот контр-аргумент похода https://isocpp.org/wiki/faq/exceptions#exceptions-avoid-spreading-out-error-logic

Ответ на это лежит ровно перед этим же сообщением.

Да, Я не пытаюсь кого-то переубедить, мне интересно что вы думаете про intermixing обработки ошибок и основной логики. В моем понимании применение excepted ни чем особо не лучше return codes, кроме композиции в 1 объект

Я про это и написал. Там нет этого смешивания т

Наоборот. У тебя есть возможность написать как раздельную обработку ошибок так и обработку на месте.

Ок, попробую поиграться с этим

Дело именно в связывании. Ты можешь связать excepted с двумя функциями с функцией продолжения и функцией фейла

И ты попадешь только в одну из них.

Поэтому в функцию успеха тебе прозрачно приходит нормально распакованное значение.

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

Другой вариант эмулировать do- нотацию

Когда мы пишем типа

А где подробнее почитать , с примерами?

a<-getA b<-getB return a+b

Поскольку оператора <- в плюсах нет, можно сделать это хоть макросом.