Я думаю, что лучше возвращать целое число, даже если функция фактически ничего не возвращает. Возвращенные значения могут использоваться для отражения различных условий ошибки внутри функции. Есть ли какая-либо цена, которую мы платим, всегда выбирая функцию целочисленного возврата, а не функцию «void» в C++?Преобразование всех функций void в функцию non-void
У вас будут вычислительные накладные расходы, связанные с возвратом значения из каждой функции. Но хороший оптимизатор может удалить избыточные возвращаемые значения.
Это плохая идея, так как это сделает ваш код нечитаемым. Но это плохая идея по другой причине: она создает еще одну возможность для неопределенного поведения, чтобы ползти в вашу программу. Помимо main все функции, отмеченные intmust возвращение int на все пути управления.
Почему бы не использовать механизм исключения; что является идиоматическим способом?
Если у вас есть политика разработки, то Функция должна возвращать код, который сообщает вам, удалось ли это сделать, а затем изменить функции void, чтобы вернуть такое значение. Вы в конечном итоге передаете выходные параметры по ссылке вместо возвращаемых значений, и вы получите код, который не похож на идиоматический C++. Но если это только функции, которые в противном случае ничего не вернут, это просто произвольное изменение и смутит людей до конца.
Если функция не может делать то, что она должна делать, она должна вызывать исключение.
Да, цена будет приложена. Мы будем платить цену за создание кода, который менее ясен и более подвержен ошибкам.
Прежде всего, возвращение необработанного int будет ужасно идея. Как вы дифференцируетесь между функцией, тип возвращаемого значения int - это фактическое целое число, а число возвращаемого типа int - это код ошибки?
Но даже если вы набрали int -размер, int-like ErrorCode тип вместо этого, это по-прежнему плохая идея. У вас теперь есть много функций в руках, которые утверждают, что они могут привести к ошибке. Вопрос в том, какие ошибки возможны? Теоретически каждый сайт вызова должен проверять все возможные ошибки, если не обрабатывать их, а затем передавать их.
На практике это будет иметь одно из двух последствий. Либо люди следуют этому, и каждый фрагмент кода функциональности будет завален обработкой ошибок.
Или (скорее всего) люди просто уйдут и проигнорируют возвращенные коды ошибок, возможно с комментариями, такими как // this cannot fail. Это, однако, дает вам ложное чувство безопасности. При записи функции вы «безопасно» возвращаете код ошибки и предполагаете, что он будет обработан. Однако вызывающий абонент, скорее всего, с радостью проигнорирует его.
В C++, если вы хотите, чтобы вызывающий абонент знал, что произошла ошибка, вы должны использовать механизм ошибки buil-in error: исключений. Они не могут быть проигнорированы вызывающим абонентом без преднамеренных усилий с их стороны и позволяют писать код, который заботится только об интересных для него ошибках.
Да, это так. Это называется читабельностью. – PiotrNycz
У меня нет канонического ответа, но это ужасная идея. Как вы говорите разницу между функцией «void» и функцией, возвращающей «int»? Это сделает читабельность вашего кода намного хуже и нарушит правило [YAGNI] (https://en.wikipedia.org/wiki/You_aren't_gonna_need_it). –
Что здесь делать? Идея может быть неправильной, но это не означает, что голоса указывают на согласие. – Angew