LINUX.ORG.RU

Приведите доводы использовать выходные параметры у функций

 , , чистый код


0

5

Серьезно. В той же OpenCV ехал выходной параметр через выходной параметр. В итоге: непонятно, что же именно функция возвращает, надо объявлять все «возвращаемые значения» заранее. Есть риск при этом ошибиться с типом, ибо функция при компиляции может молча проглотить предполагаемый тип, а уже на этапе выполнения сказать «Нет, хозяин, не могу». Впрочем, такой подход еще много где видел. Зачем и почему?

Ответ на: комментарий от Kroz

Кутешный QString::toInt() с параметром bool* посмотри, например. Это выходной по сути параметр, при том, что у функции и результат есть, который число возвращает.

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

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Кутешный QString::toInt() с параметром bool* посмотри, например. Это выходной по сути параметр, при том, что у функции и результат есть, который число возвращает.

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

Невозможность выполнить функцией прямую задачу (в данном случае конверсию в число) точно является исключительной ситуацией, то есть должна триггерить exceptional flow; ошибка это или нет - это вопрос больше логики конкретной программы, чем синтаксиса языка. В данном случае это точно должно быть исключением.

P. S. На самом деле есть один сценарий, где «не всё так однозначно» (С) - warning. Например, QString::toInt() могло бы быть реализовать так, чтобы, например, «64kb» превращалось бы в 64, но дополнительно возвращался бы warning о том, что на самом деле в параметре было не только число; далее вышестоящая логика могла бы принять решение, это ожидаемо или нет. То есть нужно возвращать и результат, и warning - два значения. Типового паттерна я на это не знаю; в Python есть отдельные Warning исключения, но как по мне это неудобно. В своих имплементациях я в функции добавляю параметры вида allow*. Например, в случае QString::toInt() можно было бы передать allowNonStrictConversion, и если он false (то есть с точки зрения логики не ожидается что в параметре не что-то кроме числа), то оно бы бросало exception, а если true, то нет. То есть это ветвление передаётся в функцию. Это делает код более читаемым.

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от Kroz

Например, QString::toInt() могло бы быть реализовать так, чтобы, например, «64kb» превращалось бы в 64, но дополнительно возвращался бы warning о том, что на самом деле в параметре было не только число

не надо этих нечетких логик. а kb64 - это число? а x00x - число? возникнет лишний набор правил, совершенно ненужных.

есть число и нечисло. а недочисел, получисел и проч. быть не должно.

alysnix ★★★
()
Ответ на: комментарий от Kroz

Тогда exception

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

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

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

бить по пальцам за геттеры/сеттеры/виртуальные функции/ехсепшены и т.д. и т.п;-)

О, так вы из религиозных…

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от Kroz

Нет, это не религия, это образность изложения и констатация фактов. Вы не согласны с утверждением, что в разных областях разные стандарты разработки?

AntonI ★★★★★
()
Последнее исправление: AntonI (всего исправлений: 1)
Ответ на: комментарий от AntonI

Нет, это не религия, это образность изложения и констатация фактов. Вы не согласны с утверждением, что в разных областях разные стандарты разработки?

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

Кстати, если вас не устраивают исключения, вам не нужны виртуальные функции - вам точно С++ нужен? Может вы не тот инструментарий выбрали?

Kroz ★★★★★
()
Последнее исправление: Kroz (всего исправлений: 1)
Ответ на: комментарий от Kroz

«Бить по рукам» без объяснения, а тем более «переучивать» С++-шников - извините, но это религия.

Вы хотите что бы я вам сейчас здесь в одном сообщении озвучил стандарты разработки HPC кодов и аргументацию почему эти стандарты именно такие?!

вам точно С++ нужен?

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

Кстати перегрузка операций где то считается нежелательной, а нам без неё никуда. Вы сейчас наверное затребуете объяснений почему:-)

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Вы хотите что бы я вам сейчас здесь в одном сообщении озвучил стандарты разработки HPC кодов и аргументацию почему эти стандарты именно такие?!

Хотябы почему исключения не используете - да. Мы, конечно, похоливорим, наверное, может быть, но может я что-то новое для себя узнаю.

Kroz ★★★★★
()
Ответ на: комментарий от Kroz

В HPC первые две буквы это High Performance. Хотя нынешняя реализация исключений конечно ушла далеко вперёд, тем не менее специалисты утверждают что поддержка исключений затрудняет оптимизацию кода и рекомендуют везде где возможно втыкать noexecpt

Кроме того по дизайну исключения к нам не очень вписываются - если где то что то пошло не так обычно выводится стек и вызывается abort

AntonI ★★★★★
()
Ответ на: комментарий от AntonI

Втыкать везде noexcept?! А вы в курсе, что это может привести к потере скорости.

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

С другой стороны, чтобы нормально, т.е. без глупого проседания скорости работала семантика move, нужен noexcept для вызова конструкторов перемещения. Здесь noexcept крайне желателен, иначе при включенных исключениях получим дополнительное копирование объектов перед вызовом таких конструкторов. Ох, уж этот бедный конструктор для std::map!

После этого, конечно, хочется взвыть, повесить портрет любимого Страуструпа на кольцо для игры в darts, или просто перейти программировать на rust…

anonymous
()