Почему дифференцируются между методами, которые возвращают значение и методы, которые не делают?
Для ref Ключевое слово Уже упоминалось в MSDN , что:
Не следует путать концепцию передачи по ссылке с концепцией ссылочных типов. Эти два понятия не совпадают. Параметр метода может быть изменен с помощью ref независимо от того, является ли он типом значения или ссылочным типом. нет бокса типа значения , когда он передается по ссылке.
Что касается ключевого слова out:
Ключевое слово out позволяет передавать аргументы по ссылке . Это аналогично ключевому слову ref , за исключением того, что ref требует, чтобы переменная была инициализирована до ее передачи.
2 ответа
Потому что в первоначальных концепциях теории и практики компьютерных наук функции и подпрограммы практически не имели ничего общего друг с другом.
FORTRAN обычно считается первым языком, который реализовал оба из них и продемонстрировал различия. (Ранний LISP также играл в этом несколько противоположную роль, но не имел большого влияния за пределами академических кругов).
Следуя традициям математики (частью которой была CS еще в 60-е годы), функции рассматривались только как инкапсуляция параметризованных математических вычислений, предназначенных исключительно для возврата значения в большее выражение. То, что вы могли назвать это «голым» (F = AZIMUTH (SECONDS)), было просто тривиальным вариантом использования.
Подпрограммы, с другой стороны, рассматривались как способ назвать группу операторов, предназначенных для оказания некоторого эффекта. Параметры значительно повысили удобство их использования, и единственная причина, по которой им было разрешено возвращать измененные значения параметров, заключалась в том, что они могли сообщать о своем состоянии, не полагаясь на глобальные переменные.
Таким образом, у них действительно не было концептуальной связи, другое чем инкапсуляция и параметры.
Настоящий вопрос заключается в следующем: «Как так много разработчиков пришли к тому, что они стали одинаковыми?»
И ответ на этот вопрос - C.
Когда K + R изначально проектировал свои высокоуровневый язык макроассемблера для PDP-11 (возможно, начался на PDP-8?), у них не было иллюзий относительно аппаратной независимости. Практически каждая «уникальная» особенность языка была отражением машинного языка и архитектуры PDP (см. I ++ и --i). Одним из них была реализация, что функции и подпрограммы могут быть (и всегда были) реализованы идентично в PDP, за исключением того, что вызывающая сторона просто проигнорировала возвращаемое значение (в R0 [, R1]) для подпрограмм.
Так родился указатель void, и после того, как язык C захватил весь мир программирования, возникло ошибочное представление о том, что этот артефакт реализации HW / OS (хотя и верен почти на каждой последующей платформе) был таким же, как семантика языка.
Я задавался вопросом об этом, поэтому в Visual Studio 2008 я создал новый проект приложения Windows Forms, используя C ++ / CLI в качестве языка. Первое, что он сделал, это выдал ошибку. Я воспринял это как показатель того, что этот материал еще не совсем готов к использованию. Может быть, я не даю ему достаточно шанса!
Файл 'c: \ source \ Test \ Test \ Form1.h' не поддержка синтаксического анализа или генерации кода потому что он не содержится в проект, поддерживающий код.
Это происходит всякий раз, когда я пытаюсь открыть созданный мастером файл Form1.h.
Это имеет то преимущество, что также запрещает if (x = true) , что было бы разрешено правилом на основе типов в контексте, где присваивания являются выражениями, которые имеют значение своего правого операнда.
В a язык, который инкапсулирует эффекты с монадами, важным различием становится различие между:
- функциями, которые возвращают
(), которые являются чистыми функциями и могут возвращать только одно бесполезное пустое значение, называемое()или дивергентные - функции, которые возвращают
IO ()(или единицу в какой-либо другой монаде), которые являются функциями без «результата», кроме эффектов в монаде IO (или какой-либо другой)