Почему не делают в ЯВУ возврат из функций несколько переменных?

Вроде бы несложно было бы объявить функцию типо так:
(int,int,char) funcname(char);
а потом аналогично использовать при вызове:
(a,b,c) = funcname('A');
причём даже в некоторых местах так:
(,,e) = funcname('A');
таким образом не используя часть переменных/регистров

То есть по сути ситуация аналогичная передаче параметров через регистры, когда (ну например в АРМ) первые 3 параметра передаются в регистрах. И возврат результата по логике строго аналогичен процессу передачи параметров, только не "в", а "из". Обычно возврат нескольких параметров делают через передачу ссылок, что в некоторой степени универсальнее, т.к. можно часть ссылок не использовать в зависимости от "нити" алгоритма. Однако, такой способ требует выделение места в стеке или в другой раме под ссылочные переменные. Что на современном уровне компиляторостроения не есть гуд. Хранение и передача (возврат) переменных в регистрах - предпочтительнее.

Сообщение отредактировал Omen_13 - Feb 22 2010, 14:14

Оккам не одобряет.

Для софт-процессора с 1К "регистров" у меня результаты функции можно хранить статически, поэтому после "funcname('A')" можно использовать в выражениях(и т.п.) a.funcname ... с.funcname (и т.д. и т.п.). Минимум пересылок.

ну, всё зависит от того, о каких ЯВУ вы говорите. т.е. утверждение собственно говоря изначально не верно, т.к. в современных языках программирования такая возможность есть (Python, Lua, Ruby...)
почему этого не было в Си? ну такая вот концепция была выбрана для этого языка далеко не самого высокого уровня, а потом унаследована Си-подобными языками, а всё потому, что не было достаточно развитых структур данных (точнее их специально старались держать попроще). с другой стороны по упомянутой мною концепции языка, функция ~ переменная, т.к. вызов функции возможен внутри выражения, т.о. если не вводить в язык достаточно абстрактные типы данных как встроенные типы, то компилятор не сможет разобрать выражение.
ну в общем примерно в этом направлении. суть такова, что те языки о которых вы думаете, не являются достаточно высокоуровневыми в нынешнем понимании, а причин, почему было сделано именно так в Си-подобных языках, достаточно много, начиная от оптимизируемости кода компилятором, заканчивая тем что это было невозможно из-за уровня развития технологии.

Да, я говорю о Си к примеру. Паскаль аналогично. Даже если раньше что-то мешало, то могло бы "прокатить" в новой ревизии. По поводу "функция ~ переменная" - ничего этого не мешает введению. Стандарт мог бы выбрать любой из вариантов:
1. Такой "сложный тип" не применяется в выражениях
2. В выражениях применяется первый тип, заключённый в скобках, с присутствующей переменной. Переменные в скобках могут опускаться, но не все сразу.
3. ---//--- последний тип.

По крайней мере Си достаточно мощный язык и он наверняка ещё долго будет жить.

В Паскале (старом) тоже, кстати, одна явная недороботка присутствует. Это вызов функций/процедур без скобок после имени. Минус в том, что внутри функции такой синтаксис мешает читать текущее значение функции, т.к. компилятор воспринимает обращение к имени функции как её вызов. В Делфи из-за этого ввели спец. идентификатор Result. Получилось криво ИМХО.

конечно, если очень захотеть, можно в космос полететь, но к сожалению история не терпит сослогательных наклонений и концепция языков того времени была выбрана именно такой. менять её кардинально не будут 1) т.к. там есть и более насущные задачи /например те же рег.выр. до сих пор не стандартизованы/ 2) и самое главное это не баг, это фича (!!!)
всех недовольных можно послать к языкам в полной мере обладающих множественным присваиванием

Представьте себя на месте разработчиков компилятора и оптимизатора. Крыша не съедет от количества вариантов?
Вот их и пожалели. Тем более, что писал компилятор тот, кто синтаксис продумывал.

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

Это только половина "зла". Переменная всё равно будет нах-ся в раме. Универсальную ссылку на регистр ещё не придумали
Хотя в AVR8 такое можно "провернуть", но это будет для компиляторописателя экстрим покруче того, что я предлагаю.


Вы всегда и всё делаете не так. Меня это не удивляет.

CaPpuCcino, но ведь дакой синтаксис не отменяет ничего уже существующего. Он только расширяет и ничему не мешает. Why not?

Сообщение отредактировал GetSmart - Feb 22 2010, 15:03

да, я ж говорю, что это возможно, но это не вероятно, т.к. при выходе из своей концепции это будет уже другой язык. и потом ведь множественной присваивание это всего лишь мнемоника. возьмите и в пределах того же С++ опишите соответствующий объект и переопределите правила оперирования с ним и будет вам то же самое O1=O2(х1,х2,х3) с возвратом целого списка аргументов и приведением к какому-то одному правилу, если объект стоящий справа "одномерный"

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

Если Вы пытаетесь рассказывать о 'C', то там передачи параметров по ссылке нет. Совсем нет. Ибо указатель это НЕ ссылка. А в плюсах есть передача параметров по ссылке и посему "придумывать" уже не надо. В обычном 'C', как уже писал, дело сложнее, но принципиальная возможность передать функции не модифицирующей указатель в регистре вместо указателя на int в регистре сам int есть.

1. Можно сказать, что я перепутал ссылку с указателем. Указатель
2. Не понял что это.
--------------------------
Ещё бы допускалось в командах break и continue (кстати, одинаковые для Си и Паскаля) указывать параметр вложенности = 1 по умолчанию. Тоже ничему не противоречит и не мешает.

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

Честно говоря, тоже не понимаю зачем это надо. Как то тоже не возникало необходимости.

Единственное, что я пользовал в Pascal, а в С этого нет - так это вложенные процедуры.
Типа:

Смысл, что переменные i,j являются видимыми для b и локальными для остальных.

Раньше, мне казалось, это существенным ограничением. Теперь, посмотрев как компилятор работает с переменными, вижу что концепция C, в принципе как раз верна.

==========================
Давайте глубже посмотрим на Вашу претензию. Например ч/з призму того же AVR.
Итак допустим у нас есть такая возможность. Как компилятор раскрутит. Фактически обращение к параметрам больше 2 будет осуществляться косвенно. Иными словами не быстрее, чем при обращении к статическим переменным. А в ряде случаев медленнее.
Так зачем этот прикол? Просто для простоты оформления/написания, для абстрактности? Так для этого имеются средства в виде интегральных типов, в том числе объектов и структур.

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