正格評価を行うほとんどの命令型プログラミング言語において、関数等における引数の渡し方(呼び方)は三種類に分けられます(他にもあるのですが、言語が限られてマイナーですので除外します)。第一の渡し方は「値渡し(pass by value)」、第二の渡し方は「参照渡し(pass by reference)」ですが、最後の第三の渡し方についての名称が今回の質問です。
第三の渡し方は、Javaの参照型、C#の参照型、ECMAScript(JavaScript)のオブジェクト型、Python、Ruby等の現代的なオブジェクト指向でオブジェクトを扱う場合に多く用いられています。オブジェクトそのものコピーして渡すのではなく、オブジェクトを共有できる形で渡す方法です。しかし、この方法について、多くの記事やサイトで__参照渡し__の名称が使われ、多くの誤解を産んでいると思われます。この間違った名称の付け方は、この渡し方に対する名称が統一されず、うまく浸透していないのが原因では無いかと思います。
ここまで読んで、第三の渡し方の名称は「○○渡しの事だ」とぱっとわかる方がどれだけいるのでしょうか?こんなのわかって当たり前と思えないほど、無理解が広まっているのでは無いかと思っている次第です。
と言うことで、第三の渡し方の名称について、統一し、啓蒙しようと思うのです。しかし、何に統一すれば良いのかを迷っているため、皆様の意見を聞きたいのがこの質問です。下記に名称の候補あげますが、これ以外でもかまいません。どの名称が良いのか、なぜ、それが良いのかの説明も添えてお答えください。
- 共有渡し(pass by sharing)
共有とは何を示すのかもわかるようにお願いします。 - オブジェクト渡し(pass by object)
オブジェクトとは何を示すのかもわかるようにお願いします。 - 共有オブジェクト渡し(pass by object-sharing)
上二つ合わせた形で冗長ですが、なぜ冗長な表現にすべきも併せて説明ください。 - 参照の値渡し
対訳となる英語なし。Java等における実装を示す名称と思われますが、Rubyの即値のように実装上は値渡しになる場合は、どう解釈すべきかも併せて説明ください。 - 参照渡し(pass by reference)
C#のref付きの第二と参照型の第三の両方の渡し方もある言語では、どのように区別するのかを併せて説明ください。 - アドレス渡し(pass by address)
C#のポインタ(アドレス)に対する第一と参照型の第三の両方の渡し方もある言語では、どのように区別するのかを併せて説明ください。 - ポインタ渡し(pass by pointer)
C#のポインタ(アドレス)に対する第一と参照型の第三の両方の渡し方もある言語では、どのように区別するのかを併せて説明ください。 - 値渡し(pass by value)
値渡しの一種なのだから、そもそも区別しないという。Cなどといった通常の値渡しとの違いはどう考えるべきかを併せて説明ください。 - 名称無し
評価戦略についてそれぞれ名前をつけてカテゴライズすること自体が間違っているということ。なぜ、そういったカテゴライズすること自体が間違っているのかを説明ください。 - コードで説明
コードで第一で、とにかくコードで説明してしまうと言うこと。詳しくはthink49さんの回答を参照してください。 - 共有呼び、すなわち参照の値呼び
必ず二つの名称を続けて言うこと。また、「○○渡し」でなく「○○呼び」になります。詳しくはxebmeさんの回答を参照して下さい。
また「○○渡し」より「○○呼び」の方が良いという意見があれば、併せて記述いただければと思います。
問題解決と言うより、意見募集のような形になって申し訳ないですが、一人で悩んでも、納得できる決定ができませんので質問しました。ただ、こういう質問も許されるのが、某スタック・オーバーフローには無いteratailの緩くて良いところだと思っています。
【追記(2019-04-23)】
長い間(一年以上)、他に回答が来なかったのでベストアンサーを選んでしまっていますが、回答していただいても構いません。Qiita界隈では「参照の値渡し」というべきでは無いと考える方がおられるようですので、そのような方の回答をお待ちしております。
参考資料
- Evaluation strategy - Wikipedia
記事では"call by sharing"として紹介されています。日本語版Wikipediaの評価戦略の項目では、この質問でのベストアンサーを基に「参照の値渡し」として私が編集しましたので、参考にしないでください。 - Rubyist Magazine - 値渡しと参照渡しの違いを理解する
記事では「参照の値渡し」として紹介されています。
気になる質問をクリップする
クリップした質問は、後からいつでもMYページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
回答8件
0
こんにちは。
確かに用語に混乱が見られるので、自分なりに整理してみました。
結論としては、「渡し方には値渡しと参照渡しの2種類しかない」ということになりました。
質問にある第三の渡し方は単なる「値渡し」であり、渡す内容が「reference typeのポインタ"値"」であるという解釈です。
この解釈に沿うと、全ての動作が矛盾なく説明できると思います。
ほとんどの言語での標準が「値渡し」であり、C#でrefキーワードを用いた場合等の特殊な場合のみ、値への参照そのものを渡す「参照渡し」に該当することになります。
第三の渡し方のようなものが存在するように見えるのは、引数に値を引き渡す際に、その「値」として持っているものがデータそのものである場合(C#の値型)と、ヒープ上のオブジェクトを指すポインタ値(参照型)である場合の違いであり、それは渡し方とは全く関係ないのです。
投稿2017/07/20 05:22
総合スコア4105
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2017/07/20 05:33
2017/07/20 06:14
![guest](/img/icon/icnUserSample.jpg)
0
Javaからみた評価戦略
Java の場合、引数はすべて値のコピーでしかも正格です。縦軸の型をみるとJavaはローレベルな言語なのがわかります(関数型インタフェースの組み合わせ爆発を招く原因になっています)。横軸の引数の渡し方は業界標準(古くからある実装技術)と思うものを挙げました。
variable type | call by value | call by reference | call by name |
---|---|---|---|
primitive type | ◯ | - | - |
reference type | ◯ | - | - |
ラムダ式が登場して call by name の機能が注目されたので以下のようにも書けます。call by sharing も追加しました。わかるのは、概念が直交していない、機能に共通部分か、依存関係があることです。
variable type | call by value | call by reference | call by sharing | call by name |
---|---|---|---|---|
primitive type | ◯*1 | - | - | - |
reference type | ◯*1 | - | ◯*2 | ◯*3 |
註
- *1 「call by value」は省略できない。理解するには、スタックに引数を積む機能とヒープのオブジェクトを参照する機能を知る必要がある。この知識を要求するのはやはりローレベルだと思う。
- *2 「call by sharing」理解するには、*1 があればよいが、スレッドごとのスタックからヒープのオブジェクトが共有参照されることを付け加えてもよい。
- *3 「call by name」理解するには、遅延評価(引数として渡された式が、呼び先で式を使う都度、評価される)を、引数の関数型インタフェース(Supplyer)のapply()メソッドを呼ぶことで実現している。さらに式が参照する変数も「値渡し/コピー」として渡されることを知る。(関数は引数をとることができるが 、引数を取らない関数に限定)
理解のレベルの考察
必要なのは call by value だけ。プログラミングするうえで困るから。それ以外は、既存のJava機能の帰結か、追加機能として理解すればよい。
機能実現の抽象レベルの考察
- call by value ローレベルな言語実装(オブジェクト指向以前から存在する標準的な技法)
- call by sharing ヒープにオブジェクトが存在することから帰結する意味論ですね。オブジェクト指向の登場のときオブジェクト共有は新しい概念だったかもしれない。
- call by name ローレベルな言語実装(ALGOL 60 から存在する標準的な技法)分散処理で関数型言語の優位性が注目されるなかで、オブジェクト指向の世界で関数型インタフェースを定義し、thunkと同様な機能を実現した。javascriptがこの機能を持っていることを改めて認識。
Java における call by sharing の位置付け。「オブジェクトの共有」は暗黙の了解事項であるが名前を付けて意識するほどのことではない。しかし他の言語については、上の関連表を書いて考察しない限り確かなことは言えない。CLUの場合はどんな表になるのかは興味がある。
wikipediaに記述するなら、評価戦略という観点から、歴史的順序、標準化の程度、依存関係、抽象化の度合いなどを、どう規定するかが著者に求められませんか?もちろん、逆引き用語集のように網羅的、索引的な記述をしてもよいが、作業量は増えます。その作業がかえって観点確立に役立つかもしれないけれど。
Javaの引数渡しの思考実験 (2019-05-02)
Javaで、1979年の議論を実現するには次のようにする。荒唐無稽ですが。
- Call by Value オブジェクトをシリアライズして渡す。呼び元のオブジェクトには全く影響を及ぼさない(mutableのみ)ただし高オーバーヘッド。
- call by reference 仮引数をfinal宣言して破壊的代入を許さなくする。あるいは、(できるなら)メソッド呼び出しをネストしたブロックにインライン展開、内部ブロックから実引数を直接参照する。できない場合が多い。
CLU (2019-05-02)
CLUにプリミティヴ型変数はなく参照型変数しかない。関数呼び出しは仮引数に実引数の参照をコピー代入することで行う。Javaにあわせて表を作ると以下のようになる。
variable type | call by value | call by reference | call by sharing | call by name |
---|---|---|---|---|
reference type | ◯ | - | ◯ | - |
以下は言語の設計過程で行われた検討。
オブジェトをヒープ、スタックのどちらに置くか
Simula 67 がCLUの目指す設計に最も近かったが、Simula 67 はオブジェクトをスタック、ヒープの両方に置く方式を採用。CLU はすべてのオブジェクトをヒープに置く。理由は、状態遷移する mutable オブジェクトを採用したため可変長オブジェクトの更新にはヒープが有利だったのと、オブジェクトの生存期間をプロセジャのスコープより長くしたかったから。当然 GC を採用した(懸垂参照(ポインタ)の議論がちょっとある)。
ヒープ、スタック
ヒープとシングルスタックを採用する。並行処理(マルチスタック)を考えたが途中で放棄した。スレッド共有という考えはない。
オブジェト
built-in type 、 user-defined type 、 procedure / iterator の三種類。
- built-in type Javaにおけるプリミティヴ型 (immutable)、配列などの集合型 (mutable/immutable)。
- user-defined type ユーザーが定義するクラス(属性と振舞を持つ。カプセル化を実現)。clusterと呼ぶ。(function cluster)
- procedure / iterator 関数(第一級のオブジェクト)
cluster (クラス) に継承という考えはない。パラメトリック・ポリモーフィズム(Javaのジェネリックスに相当。型変数を伴いコンパイル時にチェック)を採用。cluster は抽象データ型のアイデアを実装。抽象、つまり公開する振る舞い(Javaのインタフェースに相当)と実装、表現(representation)とを分離、定義する。
オブジェクト共有
スタック上の変数はオブジェクトの実体ではない。オブジェクトの実体はヒープに存在する。変数はオブジェトを参照するのみ。ここから、複数の変数が同じオブジェクトを参照(共有する)という事態が起こる。共有の本質は参照のコピー代入である。共有はどこで起こるのか。
- スタック上の複数の変数がヒープ上のオブジェクトを共有する。
- cluster の private 変数によって、ヒープ上の複数のオブジェクトが別のオブジェクトを共有する。再帰的な自己共有や、循環的な自己共有も可能。
- 関数呼び出しによって、呼び元の実引数と呼び先の仮引数が、ヒープ上のオブジェクトを共有する。
代入においてオブジェトの実体コピーとは何かという問いがたてられ、深いコピー/浅いコピーの違いや、真の実体を代入するために、by-reference パラメータを使う代入(Alfard)などが検討された。
call by sharing 共有の何が新しいと思ったのか 1979
代入とは
- オブジェクトの本体はコピーされない
- 代入はオブジェクトの状態に影響を与えない
- 代入後、オブジェクトは変数によって共有される
引数渡しとは
- 仮引数は呼び先のルーチンのローカル変数とみなす
- 実引数の式が評価され評価結果のオブジェクトが仮引数に代入される(ローカル変数の初期化)
- この手法は、伝統的な引数渡しのなかに該当するものがほとんど見当たらない(LISPの引渡しに似ている)
伝統的な引数渡しとの相違点
- call by value オブジェクトの本体を変更したら、呼び元にも変更が見える(mutableな場合)
- call by reference 呼び元の変数のエイリアスではない。オブジェクトの本体を指している
したがって、call by sharing と呼ぶことにする。
Barbara Liskov et al., 'CLU Reference Manual', MIT Laboratory for Computer Science, Cambridge, MA, 1979
設計にかかわる議論は78項目にわたって記述されている。それらは未読。
Programming Methodology Group, CLU Design Notes, MIT Laboratory for Computer Science, Cambridge, MA, 1973-1979.
手元の記事には実装の詳細が一部だけ掲載されている。拾い読み程度。読まないかもしれない。
B. Liskov, A. Snyder, R. Atkinson et al., 'Abstraction Machanisms in CLU', CACM vol. 20 no. 8, 1977
オブジェトディスクリプタの解説では定数はスタックに置かれるようだ。その他はヒープに置く。
**by objectという用語 1992 **
1992年にリスコフは call-by-sharing という用語を使っていない。call-by-object は記述がなく、"by object"が登場するのは、変数共有を排除することで推論が容易になるというところだけ。
In fact, CLU procedures do not share variables at all. In addition to there being no free variables, there is no call-by-reference. Instead arguments are passed "by object"; the (pointer to the) object resulting from evaluating the actual argument expression is assigned to the formal. (Thus passing a parameter is just doing an assignment to the formal.) Similarly, a pointer to a result object is returned to the caller. We have found that ruling out shared variables seems to make it easier to reason about programs.
Barbara Liskov, 'A History of CLU', MIT Laboratory for Computer Science, Cambridge, MA, 1992
free variables は LISP の用語で(束縛されない)自由変数と訳せる。ここではグローバル変数のこと。
"by object" は、call-by-reference を指すとも、オブジェクトの本体を渡すともとれる。
object resulting from evaluating the actual argument expression は、正格処理として実引数の式を評価して結果オブジェクトを得ること。
1979年から1992年までの間に、call-by-sharing を使わなくなった理由は不明。
CLUを調べることで、他の回答者の議論になんとか追いつくことができました。概要だけみるとCLUは、Javaや、pythonの祖先といってよいほど似ている。pythonはCLUの嫡子でしょう。抽象データ型には触れなかったが、ほんとうの研究の成果はここにあると思います。その他、仕事で出会った古いALOGOLコードにCLU由来の考えがあったのを思い出した。
命名
英文 wikipedia で call by sharing は共通合意ではないといっているが、1979年の議論は解説する必要があるでしょう。1992年にはオブジェクトのポインターを代入すると言っているので、値渡しの範囲に分類できる。call by object は資料の中に見つけられなかったので採用しません。
英語に便利な言い方があります、等値の ', or'(すなわち)を使います。
call by sharing, or call by reference value
共有呼び、すなわち参照の値呼び
すごく常識的になりました。内容に誤りがあればご指摘ください。
投稿2019/04/28 10:27
編集2019/05/02 10:15総合スコア1081
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2019/04/28 19:09 編集
2019/05/01 20:49
![guest](/img/icon/icnUserSample.jpg)
0
ベストアンサー
参照の値渡し
Rubyの場合も、即値となってしまうのはあくまで実装の最適化に過ぎず、概念上は「参照の値渡し」と解釈して問題ないでしょう。イミュータブルなものを渡すときは「純粋な値渡し」でも「参照の値渡し」でも渡された側でできることは何も変わりません。
…というより、.NET系の「値型・参照型」×「値渡し・参照渡し」のように何通りも渡し方がある言語ならともかく、たとえばRubyは引数の渡し方が1通りしかないので、言語内の事情だけ考えれば名前をつける必要もない、ということになります。
投稿2017/07/17 22:48
総合スコア145183
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
0
終わった質問と思っていましたが、再開されたようなのでJavaScriptにおいての私見を。
用語の選別
率直に申し上げれば、掲示された、どの用語を選んでも大差はないと思います。
仮に「参照の値渡し」という用語で説明したとして、別の場所では別の人が「共有渡し」と呼ぶこともありえます。
仕様で規定されていない以上、どの用語も独自用語ですから、全ての人が使う用語を統一する事は出来ません。
最終的なゴールを「読んだ人がその概念を理解し、有識者の説明、プログラミングの書籍、技術情報サイト...etc、でその概念を正しく読みとる事」に設定するとして、一つの用語に拘るのはリスクが高いと考えます。
[解決策1] 外部サイトで全てを説明する
結局のところ、「全て」を説明するのが最もリスクが低いと考えます。
- 該当概念をコード付で説明
- 2019/04/24現在はECMAScript仕様出用語化されていないこと
- 著者によって、「参照の値渡し」「共有渡し」...etc(可能性のある用語を全て書いておく)、と呼ばれることがあること(※1)
毎回、全てを説明するのは大変ですし、仕様で用語規定されたら、不正確な用語になってしまうリスクは常にありますので、自分に編集権限のある外部サイトにその説明を書いておき、毎回、そちらに誘導するのが現実的だと思います。
(私はその目的では、GitHubを使いますが、自分の好きなサイトで問題ないと思います)
※1 説明は事実的であるのが望ましいと考えます。
あるべき論を語ると、初めに読んだ説明に引きずられて思い込みが発生する可能性があります。
「あなたは参照の値渡しと書かれましたが、某所では共有渡しと表現すべきであると書かれていました。どう思いますか。」のようなやり取りが発生するのは不毛です。
理想的にはどの用語が来ても読めるであり、表現方法は本人の意志に委ねる事になると思います。
(必要であれば、「事実」を書いた上で、それが個人的意見である事を前置きした上で持論を語ります。)
[解決策2] コードで説明する
真に確実性を追求するのであれば、独自用語を使わずにコードで説明が最良と思います。
例えば、次のように説明します。
JavaScript
1function sample (object) { 2 object.a = 2; 3 object = []; 4} 5 6var object = {a: 1}; 7 8console.log(JSON.stringify(object)); // {"a":1} 9sample(object); 10console.log(JSON.stringify(object)); // {"a":2}
JavaScriptではオブジェクトのプロパティ書き換えが共有される為、2回目のコンソール出力では、関数sample
でプロパティ書き換えされた後の値が出力されます。
しかし、変数は共有されない為、2回目のコンソール出力で []
が出力される事はありません。
(2019/04/24現在のECMAScript仕様においては、いわゆる参照渡しは存在していません)
コードに付随して日本語の範囲でロジックを説明してやれば祖語は発生しません。
最終行では言葉(参照渡し)を使ってしまっていますが、これは他所サイトの説明を読んで誤解されない為の配慮であり、自分の説明を相手に伝える目的のみであれば不要な一文です。
ちなみに、既存の概念であってもこの方法は有効だと私は考えています。
質問者の中には既存の概念を間違えて覚えている方がおり、そういう方に言葉で説明すると、間違った概念の上で解釈してしまいます。
ですので、私はよく言葉ではなく、コードで説明して下さいと主張しています。
※余談ですが、ロジックを頭の中で組み立てる時には、日本語を使わずにほぼコードだけで考えている自分がいます。
コード<->日本語の変換時間がロスになっていて、コードだけで考える方が思考が加速して楽しい。
私にとっては「コード」が主役で「言葉」は無くても困らないもの。
だから、新しい内容を覚える際には「専門用語」よりも「原理」を先に覚えます。
専門用語は原理を他人に説明するのに少しだけ時間を節約できる効果がありますが、自分が覚える分にはなくても困りません。
他人に説明するには、世界共通語の「コード」で説明すればいいので、「専門用語」の優先順位は低くなっています。
言語の違い
今回、raccy さんは複数の言語について、統合的に質問されていますが、用語や概念については、言語毎に微妙な差異があります。
他言語経験者が未経験言語の学習時に「習得済言語の概念」にとらわれて戸惑うケースはよくあることですので、言語別に説明するのが無難だと思います。
特に今回は定義が不確定なものを説明しようとしているので、言語の違いによる齟齬は出来るだけ抑えるのがベターと思います。
更新履歴
- 2019/04/24 21:35 「[解決策2] コードで説明する」を追記しました
Re: raccy さん
投稿2019/04/24 02:40
編集2019/04/24 12:35総合スコア18162
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
0
個人的に思うベターな順で並べます。
最良: 共有渡し
ギリ許せる: 参照渡し
できれば使いたくない、ケースバイケース:共有オブジェクト渡し, アドレス渡し, ポインタ渡し, 参照の値渡し
論外:オブジェクト渡し, 値渡し, 名前無し
共有渡しについて
いろいろな面で、こう呼ぶのが一番自然です。半ば消去法的にですが、一番いいのはこれと考えます。
唯一の難点は、普及していないことです。
共有とは何を示すのかもわかるようにお願いします。
呼び出し元と呼び出し先で同じオブジェクトが共有されます(オブジェクトの実態はメモリ領域への参照とオブジェクトを取り扱うための然るべきプロトコルなど、後半部分はパラダイムというか実装によって若干変わる)。
関連するものとして、オブジェクト渡しは「共有される」という現象が名前に入らず、それこそ「オブジェクトの値渡し(そういうものがあれば)」と区別する手段がないため論外。共有オブジェクト渡しは動作の説明としてはいいと思いますが、冗長なのでできれば使いたくない枠。
参照渡しについて
これで説明している書籍等もあると思いますし(出典を示せないのでとりあえずこういう書き方にしておきます)、一定の市民権を得ている以上、無視するべきではないと思います。
このトピックで問題にしている「参照渡し」とC++やC#, PHP等で使われる「参照渡し」は同綴異義語とみなし、一般的な場面では文脈から判断することにします。仕様書、ドキュメント、マニュアル、初心者向け解説など取り違えが許されない場合、適切な注意書き等を付記することにします。
C#のref付きの第二と参照型の第三の両方の渡し方もある言語では、どのように区別するのかを併せて説明ください。
言語ごとに仕様等で呼び方を規定していると思うので、個別の言語についての記述ではそれに従います。
一般的な文脈で区別が必要な場合、「参照渡し(Cでいうポインタ渡し)」「参照渡し(C#でいうref)」のように区別するか、「参照渡し(俗に言う共有渡し・参照の値渡し)」「参照渡し(俗に言う共有渡し・参照の値渡しではない)」とするか、いずにせよ区別の方法はいろいろあると思います。
アドレス渡し, ポインタ渡しについて
アドレス、ポインタが言語仕様上で規定されている言語でのみ使いたいと思います。
参照の値渡しについて
たくさん問題があり、「参照渡し」とどっこいどっこい程度だと思っています。
- そもそも「参照の値」が言語仕様上で定義されない言語では使うべきではない。アドレス渡し、ポインタ渡しと同じ。
- 「参照」と「値渡し」への理解を前提知識として要求する。pythonをはじめてのプログラミング言語として学び始めた小学生にどう説明するか? 「共有渡し」なら「共有されるんだよ」と説明できます(「オブジェクトを名前に束縛する」は先に、「関数」「コールスタック」は同時に理解させておく必要があります・・・)。
- 「参照の値を渡す」というのは動作や実装の説明であり、「値渡し」や「参照渡し」と同レイヤの説明ではない(「値渡し」と言う代わりに「値をコールスタックにpushして・・・」と説明するのと同じです)。そもそも論として、参照の値を渡さない実装で同じものを実現していたときどうするつもりなのか。
- 市民権を得ていない。おそらく共有渡しと同程度に通じない。
- しかも長くてダサい。
値渡しについて
さすがに無謀。
名前無しについて
特に支持する理由がありません。
投稿2019/04/23 19:02
編集2019/04/24 09:47総合スコア30933
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
0
結論から言えば、Java では引数の渡し方はただ一通りしかないので、それを「値渡し」のような用語を使って説明するのはむしろ混乱の元だと思います。
Java で一見値渡しのように見えるもの、参照渡しのように見えるものは、データ型の性質によるものであって、メソッドの引数の属性ではありません。プリミティブ型であれば、代入でも、メソッドの戻り値でも、引数でも値のコピーが渡されますし、参照型なら、代入でも、戻り値でも、引数でもオブジェクトへの参照が渡されます。引数の時だけ、特別なことが起きているわけではありません。
それを「引数のXX渡し」のような言葉で説明してしまうと、C# のように本当に値渡しと参照渡しがある言語に移行した時、用語の齟齬が起きて混乱するのではないでしょうか。
投稿2017/07/19 14:55
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2017/07/19 15:32
![guest](/img/icon/icnUserSample.jpg)
0
- 理想的には「オブジェクトなどを参照する値」を「参照」と呼ぶことが誤解を招く原因で, それとセットで「◯◯渡し」と改称すべき.
- 但し現実的にはそれは実現が難しいと思われるので「参照の値渡し」が落とし所. また本来の参照渡しのほうも混同され易い状況のために別の名前が欲しい
かなと思います.
投稿2019/04/23 15:56
総合スコア354
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![guest](/img/icon/icnUserSample.jpg)
0
英語の文献をたどる際にわかりやすいよう、**英語に合わせて「共有渡し」**がいいと思います。
※評価戦略読んでがっつりかえました、そしてまだ考えが全然まとまってません。コメントくれた方ごめんなさい。
投稿2019/04/23 12:44
編集2019/04/23 22:56![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
総合スコア0
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 17:35 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 17:35 編集
2019/04/23 19:13
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 19:27 編集
2019/04/23 19:40 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 20:21 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 20:35 編集
2019/04/23 22:16 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/23 22:58 編集
2019/04/23 23:22
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 05:50
2019/04/24 08:35 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 06:30 編集
2019/04/24 06:33
2019/04/24 07:12 編集
2019/04/24 07:10
2019/04/24 07:29 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:18
2019/04/24 07:20 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:21 編集
2019/04/24 07:21
2019/04/24 07:37 編集
2019/04/24 07:24
2019/04/24 07:27
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:31
2019/04/24 07:35
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:44 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:39
2019/04/24 07:42
2019/04/24 07:44
2019/04/24 07:48
2019/04/24 07:51
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:54 編集
2019/04/24 07:56 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:56
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 07:56
2019/04/24 07:57
2019/04/24 07:58
2019/04/24 08:19 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 08:14 編集
2019/04/24 08:06 編集
2019/04/24 08:14
2019/04/24 08:18
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 08:19
2019/04/24 08:20
2019/04/24 08:24
2019/04/24 08:28
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 08:31 編集
2019/04/24 08:31
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 08:51 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 09:04 編集
2019/04/24 09:21 編集
![退会済みユーザー](https://ddjkaamml8q8x.cloudfront.net/profileImages/deletedUser/icnUserSample.jpeg)
退会済みユーザー
2019/04/24 10:03
![guest](/img/icon/icnUserSample.jpg)
あなたの回答
tips
太字
斜体
打ち消し線
見出し
引用テキストの挿入
コードの挿入
リンクの挿入
リストの挿入
番号リストの挿入
表の挿入
水平線の挿入
プレビュー
質問の解決につながる回答をしましょう。 サンプルコードなど、より具体的な説明があると質問者の理解の助けになります。 また、読む側のことを考えた、分かりやすい文章を心がけましょう。