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

Структура, очень удобно и эффективно использовать.

список, структура, прочитать что в описании процедуры означает слово "Знач".

Структура. А в 7.7 - список значений с обращением по представлению методом "Получить()"

(0) Структурой удобнее.

забыл проголосовать.

Зависит от.
Если надо возвращать корректность работы (что функция отработала корректно), то на мой взгляд удобнее возврат Истина/ложь, а параметры в структуре параметров.
Если корректность не имеет смысла - то можно параметрами, можно структурой.
Опять же вопрос - как потом будут использоваться значения. Может как раз структурой для дальнейшего использования удобнее

(6) а какая разница как будут использоваться значения?
задача - функция должна вернуть больше одного значения, которые будут использоваться

(6) Вообще, считаю, идеологически правильнее не изменять формальные параметры функцией. Функция в математическом смысле однонаправлена. И у неё четко разделены вход и выход.
А если надо менять параметры внутри - надо создавать процедуру.

(8) > Вообще, считаю, идеологически правильнее не изменять формальные параметры функцией. Функция в математическом смысле однонаправлена. И у неё четко разделены вход и выход.

Простой пример: код модуля стал очень сложным, хочется раскидать разные части по отдельным функциям.

Вырезаешь куски в отдельные функции, запускаешь проверку синтаксиса смотришь каких переменных не хваттае и тупо кидаешь их в параметры.

(9) Всё так, но вместо функций тут правильнее юзать процедуры. Идеологическая мешанина процедур и функций - тяжкое наследия языка Си)

(9) так ты поддерживаешь то, то в (8) написано или нет?

(7) Ну вот пример - функция должна вернуть несколько значений, которые потом будут использовать как фильтрующие параметры. Можно вернуть список значений, а можно передать менеджер и сделать временную таблицу

(12) ну с временной таблицей это отдельная песня

(11) В целом да, но я бы не стал это возводить в абсолют.

А вариант глобальных перемен это какой вариант?

(15) плохой)

(15) В рамках модуля объекта еще туда-сюда.
Более глобальные - не стоит, имхо.

Возврат какого-нибудь списка значений тоже не ахти вариант. Сложней в разборе результата функции. Нет подсказки по возвращаемому значению. Легко перепутать "имена" возвращаемых значений. Было бы понятие типа "структуры" - вопросов бы не возникало.

(18) 1. Это кто с 7.7 не работал в которых структур не было.
2. Обращаться можно по [0],[1]

Да чего тут думать? :)

(19) И что, через полгодика вы вспомните, что функция возвращает в [0]? А тем более, если кто-то другой читать код будет. Варианты типа [0] крайне не рекомендуются во всех приличных местах/языках. Варианты типа ["НомерСтелажа"] тоже, слишком велика вероятность опечатки.

(21) Так написано же КУДА она её возвращает.

(22) Где написано? В коде вы видите что-то типа:
Парам = ПолучитьИтогиДокумента(Накладная);
Наценка = Парам[3]*Парам[2]/Парам[1];
Ну и как этот код читать? За такое в приличных местах уволить нафиг могут.

Идеологически правильнее наверное структурой, но параметрами так удобно))

(21) Список значений с представлениями позволяет обращаться по имени представления. По сути имитация структуры, которой в семерке нет.

(23) 7.7 - Парам.Получить("Количество")*Парам.Получить("Цена").. как-то так.

(25) (26) Ага-ага. А когда-нибудь потом, через полгодика, вы узнаете, что в каком-то нечасто выполняющемся куске кода вместо "Количество" вы написали "Клоичество". И хорошо еще если эта ошибка будет быстро замечена, а не приведёт к постоянным косякам за большой период.
По моему, функции, изменяющие свои параметры, это плохо, но возврат списка или структуры - еще хуже.
Если бы в языке был соответствующий тип вроде сишного union - тогда метод возврата структуры был бы хорош.

(27) а чем структура плоха? опечатка приведет к исключению

По частоте использования:
1. Структура, например, если нужно получить что-то связанное с объектом (периодические значения), но получать сам объект не имеет смысла.
2. Функция с параметром, определяющим значение чего будет возвращено.
3. Несколько функций.

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

(29) про это и говорю, что благо, и проблемы здесь нет с опечатками

winapi стаил. Функция возвращает истина/ложь  (удачно/не удачно). А в параметры кладем значения возврата. В 1с аналог свойство() для структуры.

Разбить ф-ию

часто вижу этот прием в типовых.

cdecl плохо

Если структура не класс (семантически), лучше разбить ф-ию.

(33)ни о чём не говорит типовые сейчас достаточно странные люди пишут.

(32) не получиться разбить в связанных значениях
например возвращается также ТекстОшибки

(28) Структура плоха тем что:
1. Нельзя использовать автодополнение, выше вероятность опечатки
2. Что бы при чтении кода понять, какие параметры могут возвращаться, приходится переходить к определению функции и читать комментарии к ней. Если они еще есть.
3. На опечатки нельзя проверить формально, надеемся на то, что упомянутое вами исключение выскочит при тестировании у разработчика, а не повалит у пользователей в том куске, который разработчик недостаточно протестировал.
3.1. А бывают еще любители избыточного использование Попытка Исключение. Получается вообще взрывоопасная смесь.
4. При рефакторинге могут возникнуть большие проблемы по переделке кучи мест в коде. Не решаемые полуинтеллектуальным поиском с заменой и прочими подобными инструментами.
... можно еще продолжать про недостатки, но юзверя звонят...

(0) структура либо массив

(0) соответствие быстрее структуры

Не знал, что map быстрее struct

Хеш-таблицы, понятно

(41) вчера об этом на семинаре говорили

Смотря что имеется в виду под вопросом
Если нужно вернуть все перестановки какого -либо множества, то лучше сделать так, чтобы следующая перестановка возвращалась на основании предыдущей без изменения каких либо параметров.
Если нужно вернуть линейный размеры объект - тогда лучше структура (а еще лучше - сам объект)
А если нужно вернуть сто случайных значений от 0 до 1, то лучше всего возвращать массив.
Т.е. что лучше зависит от контекста вопроса больше, чем от самого вопроса.

Если функции надо вернуть несколько РАЗНЫХ значений, не объединенных семантически в какое-то целое, значит у тебя косяк в архитектуре и это две функции, а не одна.

А, если эти значения - это атрибуты какого-то одного объекта, то возвращай структуру да и всё.

(38)
> 1. Нельзя использовать автодополнение, выше вероятность опечатки
Автодополнение в 1с много где нет? это вопрос тестирования

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

> 3. На опечатки нельзя проверить формально, надеемся на то, что упомянутое вами исключение выскочит при тестировании у разработчика, а не повалит у пользователей в том куске, который разработчик недостаточно протестировал.
Это совсем другой вопрос - вопрос тестирования.

>  3.1. А бывают еще любители избыточного использование Попытка Исключение. Получается вообще взрывоопасная смесь.
Без комментариев

> 4. При рефакторинге могут возникнуть большие проблемы по переделке кучи мест в коде. Не решаемые полуинтеллектуальным поиском с заменой и прочими подобными инструментами.
Например какие проблемы?

(44) пример такой:
функция возвращает ссылку на объект
если вернуть ссылку не получилось, то также нужно вернуть текст ошибки

(47) При данном примере оптимальнее всего возвращать сылку отдельным параметром, а ошибку - результатом функции. (если ошибка пустая - значит параметр содержит ссылку)

От ситуации зависит. п.1 будет следующим по убыванию

1

Функция должна возвращать одно значение. Если даже это структура.

(51) аргументируйте пожалуйста

(48) А возвращать в параметрах ещё отстойней.

(52) Кратко пересказать книжки М.Фаулера и Р.Мартина ?

(53) Да.

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


(54) Там много опирается на то, что функция должна делать что-то одно. А если функция должна делать что-то одно, откуда взяться чему-то второму что можно вернуть?

Возврат одного значения и изменение нужных глобальных переменных

+(55) *над текстом ошибки

(53) не нужно пересказывать, просто аргументируйте своими словами

(58) См(55). Если не убедил - просто посмотри как работает типовая Справочник.XXX.НайтиПоКоду() и аналогичные. Ни одна функция в здравом уме не возвращает текст ошибки и т.п.

возвращаю данные в соответствии или структуре.

(59) а если речь идет о взаимодействии между системами?
1с - драйвер оборудования
1с - 1с по веб-сервсису
и т.п.

(52) Чтобы она могла быть rvalue.

Чаще всего использую возврат структуры, но бывает, что в параметрах возвращал значение, а сама функция возвращала статус успешное завершения функции.

(61) Тогда Попытка + ВызватьИсключение особенно часто используются.

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

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

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

}{оливар устроили

(65) это все хорошо, но вопрос был:  какими способами вы пользуетесь

Структура/Неопределено.
Т.к считать параметры в каждом вызове - напрягает.

при желании и процедурой можно значения возвращать ))) (вернее получать в переменную)

(8) Математически операция А = А + 1 недопустима. Так что не стоит математику переносить на программирование.

(10) В Си процедур не бывает. Только функции с возвратом типа void. Так что и мешанины быть просто не может.

(23) Естественно уволить - нет проверки деления на 0.

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

(71) Для математики это будет рекурсия A<-A+1
Просто в математике = это оператор равенства.

Вставлю своё имхо:
Когда нужно передавать по ссылке и там менять:
1. Когда меняешь движения, дописываешь данные в таблицу, список.
2. Когда у тебя есть большая структура, которая содержит несколько параметров, которые ты будешь использовать и тебе нужно дополнить её.
3. Когда передаёшь "Отказ" и там меняешь его на Ложь.
4. Когда передаёшь форму и добавляешь на неё свои элементы.
5. Когда передаёшь МенеджерВременных таблиц.

Это то, что смог вспомнить.

Во всех остальных случаях нужно возвращать.

(76) из всех примеров возврат значения в параметре только там где "отказ" (отстойная конструкция этот отказ). В остальных случаях это изменение состояния существующего объекта, которое в отсутствие ООП приходится выполнять именно так.

(76) это ты описываешь, больше процедуры чем функции, по логике

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

(79) В Си как раз все замечательно. Объявил параметр const - значит менять нельзя. Не объявил - значит он может быть изменен. Потому что с учетом требований с скорости работы может потребоваться и результат вернуть, и параметры поменять.

(79) (80) В Си как раз всё просто - если параметр передан по значению (засунут в стек), то в функции будет его копия, а если по указателю, то в функции будет указатель на переменную, которую по указателю можно менять.
А вот в Си++ появились ссылки, когда передаётся как бы значение, но внутри это реализовано как указатель - то есть то, что мы имеем в 1С, если не написали Знач.

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

(81) это все круто, конечно, но оффтоп

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

(83) Дык а если надо и параметры изменить, и значение вернуть? Что использовать? А если надо вернуть значение, параметры не менять, но поменять не параметры (например, добавить записи в базу)? Деление на процедуры и функции чисто условное, иначе сам ЯП не давал бы менять параметры в функции.

В зависимости от решаемой задачи

(85) БИНГО!!!

но мне кажется структура отбирает больше памяти, чем просто переменные.

(84) "Деление на процедуры и функции чисто условное, иначе сам ЯП не давал бы менять параметры в функции."
А лучше бы не давал. С точки зрения парадигмы функционального программирования изменение формальных параметров - жуткая ересь)

(88) А ты с многопоточным программированием и реентрантностью работал? Когда один и тот же код и одни и те же переменные могут использоваться одновременно несколькими потоками? И тогда единственный способ не конфликтовать потокам - это передавать указатель на некую структуру со всем контекстом потока в качестве параметра функции? И, соответственно, параметр там в процессе работы меняется.

(89) А с распределёнными вычислениями?
Процедуре передавать аргументы по ссылке можно.

В Джаве например вообще нельзя передаваемые параметры менять, только возвращать

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

(91) Это помогло ей завоевать звание тормозящей и памятежрущей.

(91) Но, в той же java прекрасно как параметры передаются объекты-контейнеры (BOX) в которых можно менять содержимое, не меняя самого контейнера, то есть так они реализовали указатели.

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

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

(93) Там просто сборка мусора работает тогда, когда памяти стало очень мало - в результате - если память есть, то её будут жрать, пока не надоест. Но, есть ключи запуска, где всё это можно ограничить. И ваша java побыстрее 1С будет.

(89) Я дико извиняюсь, а в каком языке программирования практикуется подход обращения к общим переменным из разных потоков?

(95) Это скорее особенность компилятора. Локальная переменная функции адресуется по контретному смещению (типа [EDI + 0x10h]. Т.о. если 2 процессора выполняют один и тот же код с одним и тем же значением регистра EDI - физически 2 потока будут обращаться к одной и той же ячейке памяти. В принципе, можно для каждого потока использовать свое значение регистра EDI - но тогда для каждого потока придется создавать свою копию всего контекста приложения.

(96) не буду утомлять наводящими вопросами и приведу сразу ссылку на race condition: https://ru.wikipedia.org/wiki/Состояние_гонки

(97) Как минимум в некоторых реализациях C++ локальная переменная не поможет, поскольку она во всех потоках будет иметь одинаковый адрес. Собственно, так я и познакомился с этой особенностью многопоточной работы.

(98) Может быть потому что эта локальная переменная (переменная-член класса) была объявлена, как static?

(0) Все зависит от ситуации.
Если нужно "набрать" несколько значений, то Структурой их очень удобно возвращать.
В другой случае, через параметры принимаем значение, и через них же возвращаем (типа по ссылки).

(99) Не, в том коде вообще не было классов (как и ООП - чисто в стиле Си был код), а переменные были объявлены как int. Только отладка с показом дизассемблерного кода позволила выявить эту особенность. На это, кстати, напарывались и серьезные производители. Например, у некоторых контроллеров Promise драйвер включал кеширование - так вот оно на многопроцессорных системах иногда путало подключенные к нему диски и писало не на тот диск по случайным секторам, если в момент записи была одновременная активность по нескольким дискам.

P.S. С классами как раз все в порядке было, ЕМНИП. Т.к. обращения к обычным членам класса через ECX идут, который для каждого экземпляра класса различается.

(95) А в каких ситуациях применяются объекты синхронизации?

(102) Так я на это и намекал. Что если есть общие для потоков ресурсы, то без объектов синхронизации нельзя. Иначе будут гонки.

На самом деле, проблема многопоточного обращения появилась из того, что изначально регистры были 16-битными, а переменные 32-битными - в итоге, второй поток мог обращаться к переменной посреди операции.
Например, когда число переходит с 65535 в 65536 за несколько операций, то второй потом получает 0.
Не забываем, что оптимизатор кода может создавать копии значений в стеке, чтобы не обращаться к ним напрямую (особенно, если разыменовывается несколько указателей) и, в итоге, получается совсем не то, что хотел программист.
Опять же, если мы работаем с объектом и меняем его свойства, то желательно, чтобы второй поток нас ждал иначе будет каша.
Встроенных объектов для синхронизации в любой операционной системе предостаточно, так что всё можно сделать и решить, только получается, что если программист не очень хорошо думал, то все потоки друг друга ждут на объектах синхронизации, а программа работает медленнее чем однопоточная.

Структура/Неопределено.
Т.к считать параметры в каждом вызове - напрягает.
1. Возврат структуры

Как насчет такой задачи: происходит чтение из табличного файла и в нем разные данные(в разных колонках).

И это все надо преобразовать из текстового значения в строки(хотя бы лишние пробел обрезать или допустим в файле ратикул "00001", а в 1С "000000001"), числа, даты, справочники. Т.е. код, примерно такой


тзДанныеДляЗагрузки.Сумма = ПолучитьЧисло(стрФайла.Сумма);
тзДанныеДляЗагрузки.Колво = ПолучитьЧисло(стрФайла.Колво);
тзДанныеДляЗагрузки.ДатаДок = ПолучитьДату(стрФайла.Дата);
тзДанныеДляЗагрузки.НомерДок = ПреобразоватьНомерДок(ПолучитьНомер(стрФайла.Номер));
тзДанныеДляЗагрузки.Контрагент = НайтиКонтрагента(стрФайла.ИНН);
тзДанныеДляЗагрузки.ЕдИз= НайтиЕдИз(стрФайла.ЕдИз);

Но в файле бывают ошибки. И ошибки разные, есть кртические после которых такую таблицу вообще нельзя загружать, есть те котоыре можно руками поправить, Желательно получить сообщения типа: "В строке Х, не заполнено поле Сумма". Так же допустим ИНН несколько раз встречается проблемный.
Выводить сообщения
НЕ найден контрагент с ИНН 1234567890
НЕ найден контрагент с ИНН 1234567890
НЕ найден контрагент с ИНН 1234567890
НЕ найден контрагент с ИНН 1234567890
НЕ найден контрагент с ИНН 1234567890

Не красиво, желательно, чтобы был отдельный список проблемных ИНН и чтобы не выводить по несколько раз.

Конечно можно написать чере структуру
струкКонтрагент = НайтиКонтрагента(стрФайла.ИНН);

тзДанныеДляЗагрузки.Контрагент = струкКонтрагент .Значение;
БылаОшибка = струкКонтрагент .Ошибка;
БылаКритическаОшибка= струкКонтрагент.БылаКритическаОшибка;

струкСумма = = ПолучитьЧисло(стрФайла.Сумма);;

тзДанныеДляЗагрузки.Сумма= струкСумма .Значение;
БылаОшибка = струкСумма.Ошибка;
БылаКритическаОшибка = струкСумма .БылаКритическаОшибка;
и  т.д.

Получается засорение кода.

(96) А разве локальные переменные не в стеке хранятся?

(106) "Получается засорение кода."
А вы не засоряйте. Со структурой можно писать красиво и понятно. Придумывайте осмысленные имена переменных и функций, не дублируйте поля структуры переменными без необходимости.

(77) > отстойная конструкция этот отказ
почему?

(108) В том тои  дело, что разные  функции должны выдавать одинаковые переменные.

Я, например, такое сделал через глобальные переменные.