Перейти к содержанию
    

(Не)доработки языков программирования

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

 

Вроде бы несложно было бы объявить функцию типо так:

(int,int,char) funcname(char);

а потом аналогично использовать при вызове:

(a,b,c) = funcname('A');

причём даже в некоторых местах так:

(,,e) = funcname('A');

таким образом не используя часть переменных/регистров

 

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

Изменено пользователем Omen_13
Тема переименованна по просьбе автора

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

ну, всё зависит от того, о каких ЯВУ вы говорите. т.е. утверждение собственно говоря изначально не верно, т.к. в современных языках программирования такая возможность есть (Python, Lua, Ruby...)

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

1. Такой "сложный тип" не применяется в выражениях

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

3. ---//--- последний тип.

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Стандарт мог бы выбрать любой из вариантов

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

всех недовольных можно послать к языкам в полной мере обладающих множественным присваиванием

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Вот их и пожалели. Тем более, что писал компилятор тот, кто синтаксис продумывал.

:biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Однако, такой способ требует выделение места в стеке или в другой раме под ссылочные переменные.

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

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

А вообще за много лет программирования, как-то ни разу не пришлось возжелать того, что Вы хотите. Наверное, я что-то делаю не так :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

.. то и ссылка соответственно попадает в регистр и получаете именно то, что хотели.

Это только половина "зла". Переменная всё равно будет нах-ся в раме. Универсальную ссылку на регистр ещё не придумали :biggrin:

Хотя в AVR8 такое можно "провернуть", но это будет для компиляторописателя экстрим покруче того, что я предлагаю.

 

Наверное, я что-то делаю не так

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

 

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

Изменено пользователем GetSmart

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Why not?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

"...доработки языков программирования, которые хотели ли бы вы"

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это только половина "зла". Переменная всё равно будет нах-ся в раме. Универсальную ссылку на регистр ещё не придумали :biggrin:

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1. Если Вы пытаетесь рассказывать о 'C', то там передачи параметров по ссылке нет.

2.В обычном 'C', как уже писал, дело сложнее, но принципиальная возможность передать функции не модифицирующей указатель в регистре вместо указателя на int в регистре сам int есть.

1. Можно сказать, что я перепутал ссылку с указателем. Указатель

2. Не понял что это.

--------------------------

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Типа:

void a(void)
{
  integer i,j;

  void b(void)
  {
  }
}

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

 

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

 

==========================

Давайте глубже посмотрим на Вашу претензию. Например ч/з призму того же AVR.

Итак допустим у нас есть такая возможность. Как компилятор раскрутит. Фактически обращение к параметрам больше 2 будет осуществляться косвенно. Иными словами не быстрее, чем при обращении к статическим переменным. А в ряде случаев медленнее.

Так зачем этот прикол? Просто для простоты оформления/написания, для абстрактности? Так для этого имеются средства в виде интегральных типов, в том числе объектов и структур.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...