K.Maebashi's BBS

>[601]>ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? > >仮想アドレスの章：　はい、今　読んでみました。仮想メモリと物理メモリの話ですね。 >閲覧したいのは物理メモリです。仮想メモリもついでに見てみたいです。 特定プロセスの仮想メモリのユーザ空間（32bit OS なら、アドレスが下位 31bit の範囲に収まる部分）は、デバッガを使えば、割と簡単に見ることができます。 上位領域を見る方法をご存知の方がいらっしゃいましたら、教えていただけないでしょうか？ 物理メモリの内容は、/Device/PhysicalMemory というセクションにマップされているようです…と言っても何のことだかわからないと思います。 SysInternals で、ここを覗き見るサンプルが公開されています。 http://www.sysinternals.com/Information/TipsAndTrivia.html#PhysMem

>ここです。誤解される事を嫌がる人が多いという事です。 のまネコについて、avexがゼロから作ったものだ、という誤解というのは、 (もともとあめぞう起源らしい)モナーについて、2ちゃんで生まれたものだ、 という誤解があるのと同様でしょう。 後者の誤解のため、実際にあめぞう掲示板出身の人は怒っていたりするわけですが、 誤解をしている人がいたら、正しい情報を伝えて誤解を解けばよいのですから、 たいした問題ではないと私は考えます。たいした問題だと考える人がいてもいいですが、 その場合、あめぞうな人の主張も受け入れなければフェアではないですね。 のまネコから知る人というのは(定義からして)その時点でモナーを知らないわけですから、 その人たちに「のまネコはモナーを元にしているんだよ」ということを啓蒙できれば、 モナーを知る人の数はむしろ増えるわけです。 >モナーグッズ作成者(イラストやぬいぐるみの作成者が以前よりおります)はパクリの目で見られます。 現実問題としてこれはないでしょう。現在最もメジャーな形ののまネコと、 本来の形のモナーはほとんど似ていません。また、PVの中には(モナーというより) モララーやマダーに近いネコが確かに登場しますが、そんな誤解を懸念するなら、 誤解されないような売り方をすればよいわけです。 エヴァンゲリオンがヒットしたあと、エリスンのアレは書店で平積みになって ましたが、パクリの目で見られましたか? 片山恭一のアレがヒットしたあと、エヴァンゲリオンはパクリの目で見られましたか? >　「Avexに１つ１つ作品を見せていただいて類似性を確認させていただく事になります」 >というのがAvex社の電話回答です。 これのソースはあるでしょうか。 私が知っているのはこれだけです。 http://that3.2ch.net/test/read.cgi/goods/1126073495/28 | ‘私個人がモナーのイラストに描いてネットにアップする際、 | 似てしまうから、違いを教えて欲しい。そしてモナーグッズを個人的に作って | 売る際、著作権にひっかからないのか’ | と avexに電話で聞いてみた所、 | イラストは個人の主観で、個人がモナーを描いたと思うなら問題ない。ただし、 | グッズなどはavexに一つ一つ、聞きにきて欲しい。 | …と言っていた。 もともと私は、avexが「のまネコに関して」独占した権利を主張するのは当たり前だと 思っています(だから2ちゃんの圧力に屈して商標取り下げに至ったのは不当だと思う)。 マイヤヒのCDをひっくるめ、プロモーションには金も労力もかかります。 第三者が、目が「o」で口が「ω」の、明らかにモナーではない方ののまネコを 販売してavexの利益を荒らすのは少なくともよいことではないでしょう。 そこへ、「似てしまうのでどうすりゃいいか」という質問が電話できたら、 「弊社に確認してください」という回答以外ありえないように思います。 上記程度のソースでは、会話の正確な流れがわからないので、もし録音等の ソースをご存知でしたら教えてください、ということです。 | なんでパクッた人にお伺いを立てなくてはいけないのか | 疑問だし、そのうちイラスト、モナー系のフラッシュなども | 制限かけてきそうで怖いですね。 | そういう事しないと、文章で示してもらわないと・・・ で、avexはちゃんと文章で示したわけですよね? http://www.bmybox.com/%7Estudio_u/nomaneko/avex.php | しかし今回出願した商標につきましては、あくまでもグッズとして展開される | キャラクターの「のまネコ」のみであり、当然のことではありますが、わたしたちが、 | モナーの利用に対して権利を主張することは一切ありませんし、他のアスキーアート | （例：しぃ、モララーなど)に対しても同様です。 これ以上何を望むのでしょうか。 >「既存AAはそのまま使っていいけど、新規AAは確認してほしい」 こちらについてもソースの提示をお願いします。 いずれにせよ、電凸(電話で突撃)で聞けるようなコメントは、Webなどでの公式見解が 出ればそれに上書きされるものだと私は思いますが。 >Avex社の対応の仕方に頭にきている者も多い事を付け加えておきます。 avexの対応について、これはどうかと思うところは私もあります。 最新の公式見解なんか、確かに企業が公に発表する文章とは思えません。 しかし、2ちゃんねらの、黒FLASHやマンガAAのような明らかな著作権侵害を容認しておきながら、 のまネコ程度のパクリで著作権がどうのと騒ぎ出すダブルスタンダードっぷりや、 「きみたちのものだったという証拠はあるのかね?」とか 「君たちはもう勝手にこのねこを使ってはいけない」とか、 嘘八百を並べ立てたFLASHで同情を引こうとしたりする卑怯っぷりに http://www.geocities.jp/doronumaneko/ 腹を立てている人も最低ここにひとりはいることを付け加えておきます。 avexという大企業が、黒FLASHまで大目に見て、面白いネタに乗ってきてくれたという 流れをぶち壊してくれたことも、心底残念に思います。

こんにちは。雑記帳読みまして。。 Programingに関係なくてすみません。 私のまネコ反対派です。１個人の意見で申し訳ないですが、だいたいの総意は皆似たようなもんでして、 ･avexがいくら儲けたって、損する人はいないんだから別にいいです。 ･avexがのまネコの著作権を主張しても、モナーが使えなくなるようなことはないです。 これはその通りです。 皆が嫌がってるのは ･そういう誤解が広まることは、私にとって嬉しいことではないですが、 ここです。誤解される事を嫌がる人が多いという事です。 モナーグッズ作成者(イラストやぬいぐるみの作成者が以前よりおります)はパクリの目で見られます。 10/2現在では商標は取り下げて戴けましたがオリジナル主張し商品販売を続けておりまして、モナーグッズを作成する場合は 　「Avexに１つ１つ作品を見せていただいて類似性を確認させていただく事になります」 というのがAvex社の電話回答です。 「既存AAはそのまま使っていいけど、新規AAは確認してほしい」 と言う事もAvexの電話回答で言われております。 怒りの理由をお判りになって戴けたらありがたく思います。 Avex社の対応の仕方に頭にきている者も多い事を付け加えておきます。

こんばんは。 [603]>(B) は静的に確保したいわゆる二次元配列 char a[MX][MY] と完全互換です。 [603]>char a[MX][MY] を渡して欲しいと思っている関数には (B) だけが使えます。 なるほど。 こんど　似たようなコードを書くときには いろろ変えて遊んでみます。 おせわになりました

>ソースのわかりやすさでも、機能性とかバグ回避の点でも >（B）が優れているとは言えないわけですね。 いいえ。必ずしもそうとは言い切れません。 (B) は静的に確保したいわゆる二次元配列 char a[MX][MY] と完全互換です。 char a[MX][MY] を渡して欲しいと思っている関数には (B) だけが使えます。 ＝配列の全要素がメモリ上で連続である必然がある用途に対しては (B) でなければなりません。 fwrite こそしないかもしれませんが memset はしたくなるかもしれませんしね。 仮想記憶の話を書きましたが、容量的に char a[MX][MY] と書いて問題ない状況下に おいては (B) を避ける理由がありませんし、問題が出る状況下ではどっちにせよダメですから。 http://forums.belution.com/ja/cpp/000/000/89s.shtml とかに類似の話題がありますな。とりあえず参照してみてください。 まあ今なら vector の vector を使うほうがお勧めです(A に類似:それでよい用途なら)。 生 new なんぞ使うと delete 忘れのほうが怖いので。

ありがとうございました。 [601]>どちらもpの型はchar**ではないでしょうか。 そうです。すごく初歩的なミスで　はずかしですけど。 [601]>ただし、p[n]を個別に解放したいとか、個別にサイズ変更(realloc)したいとかの [601]>場合には(B)の方法は使えません。 [600]>なので、しょぼい仮想記憶 (というかスワップ機能) を持つOSだと問題が発生しえます。 わかりました。 ソースのわかりやすさでも、機能性とかバグ回避の点でも （B）が優れているとは言えないわけですね。 [601]>ポインタ完全制覇をお持ちなら、「2.1 仮想アドレス」を参照してください。 [601]>ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? 仮想アドレスの章：　はい、今　読んでみました。仮想メモリと物理メモリの話ですね。 閲覧したいのは物理メモリです。仮想メモリもついでに見てみたいです。 [600]>VC++ の IDE デバッガとか gdb とか、いろいろデバッガがありますね。 [600]>わざわざ作るまでも無いような気がします。 あ～、なるほど。知りませんでした。 とりあえず、デバッガを使ってみます。 [600]>>上のプログラム（B）のときのメモリ開放は [600]>>delete[] p[0]; [600]>>delete[] p; [600]>正解です。 やっぱり当然ですね。 でも、うっかり次のように書いてしてしまいそうで やっぱり(B)はあんまり良いコーディングではないですね for(y=0;y<yM;y++)delete[] p[y]; delete[] p; 以上　参考になりました。ありがとうございました。

>(A)(B)どっちが良いのでしょうか？ どちらもpの型はchar**ではないでしょうか。 それはさておき、 >ちなみに個人的な意見（というか直感）では >(A)の方がわかりやすいですね。たぶん。 >しかし、 >(B)の方が、例の「どこかの領域」を節約するため効率的と思います。 これはその通りなので、わかりやすさと効率を秤にかければよいと思います。 ただし、p[n]を個別に解放したいとか、個別にサイズ変更(realloc)したいとかの 場合には(B)の方法は使えません。 >fread(p[0],sizeof(char),xM*yM,fp); >と一発で書けて便利と思います。 そうですが、そういうことを始めると一発でデータファイルの互換性が 失われるのでおすすめはできません。 >■メモリー閲覧 >（なければ、私が自分で作ってみたいな...と思っています） 774RRさんがすでにおっしゃっているように、そういうプログラムをデバッガと 言います。 ところで、閲覧したいメモリは仮想メモリでしょうか? 物理メモリでしょうか? 他プロセスの仮想メモリを覗くのも物理メモリを覗くのも、C言語レベルで 標準的な方法は存在しないため、そんなに簡単には作れないと思います。 ポインタ完全制覇をお持ちなら、「2.1 仮想アドレス」を参照してください。

>また、(B)では、連続するデータがメモリー上に連続して確保されるはずなので ですです。 なので、しょぼい仮想記憶 (というかスワップ機能) を持つOSだと問題が発生しえます。 連続するメモリ領域全てをひとかたまりに swap したがるような OS だと、 (A) では連続領域が小さいのに対して (B) は連続領域が大きいので、 (A) より (B) のほうがスラッシングが置きやすいです。 現代OSにはそんなしょぼいものは無いですけど... >fread(p[0],sizeof(char),xM*yM,fp); >と一発で書けて便利と思います。 最近こーいうことしないからなんともいえませんね。 >上のプログラム（B）のときのメモリ開放は >delete[] p[0]; >delete[] p; 正解です。 >■メモリー閲覧 そーいうソフトのことを普通はデバッガと言いますが... VC++ の IDE デバッガとか gdb とか、いろいろデバッガがありますね。 わざわざ作るまでも無いような気がします。 ただメモリが見えるだけではつまらないので。

■delete a[];はエラーか？ >> x=new char[n]; を開放するときは delete x[]; >>という人もいますが、これは間違いではないでしょうか。 > >そもそもそんな書き方ってできましたっけ。 柴田望洋さんとういう方の次のHPには http://www.bohyoh.com/CandCPP/FAQ/FAQ00085.html new/deleteのサンプルリストがあって int *a = new int[no]; /* 確保 */ //中略 delete a[]; /* 解放 */ とあります。 気になったので、今、Borland C++5.5でコンパイルしてみると コンパイルエラーで叱られました。 ＃投稿した後でテストするあたりは、ものぐさなもので、 　すいません。（あ、石投げないで） ■２次元配列の動的確保 ところで、また教えてください。 xM列yM行の２次元の配列p（というか配列もどき）を確保するときは Borland C++5.5　のマニュアルによると （program A） char *p;p=new char *[yM]; for(y=0;y<yM;y++)p[y]=new char[xM]; とあります。これは、次のように書いても良いと思います。 （program B） char *p;p=new char *[yM]; p[0]=new char[xM * yM]; for(y=1;y<yM;y++)p[y]=p[0]+y*xM; (A)(B)どっちが良いのでしょうか？ ちなみに個人的な意見（というか直感）では (A)の方がわかりやすいですね。たぶん。 しかし、 (B)の方が、例の「どこかの領域」を節約するため効率的と思います。 また、(B)では、連続するデータがメモリー上に連続して確保されるはずなので fread/fwriteなどの場合 fread(p[0],sizeof(char),xM*yM,fp); と一発で書けて便利と思います。 この点、みなさん、どうお考えですか。 ■２次元配列の開放 上のプログラム（B）のときのメモリ開放は delete[] p[0]; delete[] p; ですよね。 （初心者なのでなんとなく自信がないです。くだらない質問ですいません。） ■メモリー閲覧 最後に、メモリー操作の結果を確認するソフトというのは 何かありますか？（メモリー閲覧ソフト？） つまり、このソフト自体は指定されたアドレスに常駐させておき キーボードなどでアドレス範囲を指定すると そこのメモリーのデータが10進数で表示される というものです。 （なければ、私が自分で作ってみたいな...と思っています） 以上、お願いします。

はじめまして （と、前回の登校文に書くのを忘れていました）。 （ぱ）さん、774RRさん さっそくのお返事、ありがとうございます。 参考になりました。

あうー explicit_constructor_call が抜けた... for (size_t i=0; i<n; ++i) explicit_constructor_call(&p0->array[i]); を new[] の中に追加しといてください。 # 表記は placement-new および t->~T() ; でもよかったわけだが、まあいいや

すでに完璧な答えが出てますが、一応フォローをば。 >>ところで　delete と delete[] はどう違うのでしょうか。 >>両者を取り違えると不都合があるのでしょうか。 はい、言語仕様上「未定義」つまり、「誤りであり、何が起きても文句は言えない」状態です。 不都合が生じても一向に構いませんし、プログラマの期待通りに動いても構いません。 >> x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが >>このときのnの値（開放すべきデータのサイズ）は >>メモリのどこに保存されているのでしょうか。 言語仕様は何も定めていません。なのでまさに >「どこかの管理領域」としか言いようがないです が、実装を簡単にするために、こんな手が使われることが多いです。 T* p=new T[n]; は内部で struct anonymous_n_array_of_T { size_t n; // この n の前後に padding が入ることもあります T array[n]; }; anonymous_n_array_of_T* p0=malloc(sizeof(anonymous_n_array_of_T)); p0->n=n; return &p0->array[0]; 同様 delete[] p; の内部処理は anonymous_n_array_of_T* p0=translate_pointer(p); // get p-sizeof(size_t) for (int i=p0->n; i>=0; --i) explicit_destructor_call(&p0->array[i]); free(p0); // 説明のためにいろいろ略:キャストの明示など よって new/delete[] や new[]/delete をしてしまうと、正しく配列要素数が取り出せず 誤動作してしまうのです（デストラクタが呼ばれすぎ・呼ばれないなど）＝未定義動作 VC++ など一部のコンパイラでは POD (plain old data) 型 (char/int など) の new[]/delete[] が単純な malloc/free になっているので new[] を delete しても動いてしまい、問題が発覚しにくくなっています。 その昔、開発中の C++ では delete[n]p; と要素数の指定が必要でした。 これはあまりもアレげなので現在の仕様になった、と D&E にあります。

> x=new char; とした後、これを開放するときは delete x; > x=new char[n]; とした後、これを開放するときは delete[] x; >となっていると思います。 >ところで　delete と delete[] はどう違うのでしょうか。 >両者を取り違えると不都合があるのでしょうか。 C++はさして詳しいわけではないのですが。 仕様上はおそらくこの場合の挙動は不定で、「何が起きても文句は言えない」状態だと 思いますが(ちゃんと調べてませんすみません)。 現実問題としてありそうなのは、charのような基本型でなくクラスの配列の場合、 最初のひとつのオブジェクト以外のデストラクタが呼び出されない、ということでしょう。 >また、もちろん > x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが >このときのnの値（開放すべきデータのサイズ）は >メモリのどこに保存されているのでしょうか。 「どこかの管理領域」としか言いようがないですが(管理方法によっては、 サイズを直接保持する必要はないかもしれません)。 動的メモリ確保の挙動については、ポインタ完全制覇の2-6-3あたりを参照して ください。C++でも、ずっと下の方では、特に変わるものではありません。 逆に言うと、Cと同レベルのメモリ管理機構の上にC++をのっけてしまったから、 プログラマの側が忘れず[]を付けることを強制されているとも言えるでしょう。 >それから > x=new char[n]; を開放するときは delete x[]; >という人もいますが、これは間違いではないでしょうか。 そもそもそんな書き方ってできましたっけ。 Bjarne本の第3版の構文規則を見ると、 delete-expression: ::opt delete cast-expression ::opt delete [ ] cast-expression とありますが… すみませんどなたか詳しい方の救援をお願いします。

>ダウンロードしようとしたら、UNIX版のtgzファイルがver.0.3.01とver.0.3.02で同じになってました。 … >if (5 < 8) { > print("5 < 8\n"); >} else { > print("5 >= 8\n"); >} > >を実行すると怒られました。 ご指摘ありがとうございます。まぬけなバグで申し訳ありません。 修正してアップロード途中です。最近ネットの調子が悪いようで、 GLOBALをかけたソースの途中で今止まっています。 >| Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 定数同士の比較では、解析木の畳み込みを行うのですが、論理型を追加したときの 修正漏れで、「畳み込んだ式は整数か実数のどちらかだ」というassert()が残っていました。 テスト不足ですみません。 >何で2回？ crowbarに付属するデバッグ用ルーチンは、 ・事前に設定したファイルポインタ ・stderr の両方にエラーメッセージを吐くようになっているようです。 そして、「事前に設定したファイルポインタ」は、デフォルトでstderrなので、 デフォルトでは両方に出る… ということです。 大昔に作ったものなので、今ソースを見て確認しました。ファイル指定の出力の方は 本当に動くかどうかも自信がありません (^^;

>crowbarのver.0.3.02は、9/26中には出します… ： >いやその所詮マイナーバージョンアップなんですが。 ダウンロードしようとしたら、UNIX版のtgzファイルがver.0.3.01とver.0.3.02で同じになってました。 あと、 if (5 < 8) { print("5 < 8\n"); } else { print("5 >= 8\n"); } を実行すると怒られました。 | Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 | v->type..1 | Assertion failure (v->type == CRB_DOUBLE_VALUE) file..create.c line..187 | v->type..1 | アボートしました 何で2回？

前橋さんの「C言語 ポインタ完全制覇」 とても面白かったです。 さて、この本と少ししか関係がないので申し訳ありませんが Cの文法によると、 x=new char; とした後、これを開放するときは delete x; x=new char[n]; とした後、これを開放するときは delete[] x; となっていると思います。 ところで　delete と delete[] はどう違うのでしょうか。 両者を取り違えると不都合があるのでしょうか。 また、もちろん x=new char[n]; の後の delete[] x;　でchar型のn個の領域が開放されますが このときのnの値（開放すべきデータのサイズ）は メモリのどこに保存されているのでしょうか。 それから x=new char[n]; を開放するときは delete x[]; という人もいますが、これは間違いではないでしょうか。 以上、お願いします。

400000です… くだらないことですいません…。

>crowbarのver.0.3.02は、9/26中には出します… 日本語関係は、ISO-C の mbr/wcs 系関数 (1バイトずつ処理するなら mbrtowc(3)) を使うのはどうですか? 想像だけど、これで Windows なら wchar_t は Unicode になるん じゃないでしょうか。(UNIX 系だと wchar_t 表現も locale 依存に なります。Linux の場合は Unicode) これが存在しない古い OS では1バイト文字だけサポートするとか。

crowbarのver.0.3.02は、9/26中には出します… と言っておかないとずるずる遅れていきそうなので (^^: いやその所詮マイナーバージョンアップなんですが。

>さて、リターンした後ですが、main()側は、aとb両方のアドレスを >知っているわけです。なので、bのアドレスをスタックなどに積む必要は >ないのでは、と言いたかったわけですが。 なるほど(^-^;) 了解です。

>>Pascalではprocedureのネストが可能で、 >>呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 > >C言語に変数引数を追加した言語でも、グローバル変数を使えば同じことが起きませんか？ あ、そりゃそうだ f(^^; いろいろ見逃してましたね。ご指摘ありがとうございます。

>Pascalではprocedureのネストが可能で、 >呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 C言語に変数引数を追加した言語でも、グローバル変数を使えば同じことが起きませんか？

>>呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 >>関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。 >そうですそうです。 >なので「コピー先（元）がどこ？」って情報がどこかには必要ですよね。 ええと、C(C++?)風擬似言語で、 void hoge(int &a) ←変数引数の宣言 { printf("%d", a); a = 10; } int main() { int b = 20; hoge(b); } と書いたとき、 (1)通常のCの関数呼び出しと同様、main側で、bをスタックに積む。 (2)よって、hoge()のprintf()では、20が表示される。 (3)hoge()内の「a = 10;」により、引数aに10が設定されて、リターン。 さて、リターンした後ですが、main()側は、aとb両方のアドレスを 知っているわけです。なので、bのアドレスをスタックなどに積む必要は ないのでは、と言いたかったわけですが。

>呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 >関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。 そうですそうです。 なので「コピー先（元）がどこ？」って情報がどこかには必要ですよね。

>ただ、その場合でも関数から戻ってきた際のコピー先を引数として渡さなくても、 >暗黙的にはスタックとかに積んでおく必要がありそうですね。 呼び出し側で、通常の値渡しと同じように現状の値をスタックに積み、 関数から戻って来たところで、呼び出し側でコピーを行えばよいのでは。

まずお詫びと訂正ですが、[575]でURLの訂正をしましたけれど、 [576]でまた間違ったほうのURLを貼ってしまいました。正しいのは http://java-house.jp/ml/archive/j-h-b/028873.html#body です。 >話は完全にそれますが、この JavaHouse での記述は誤りですね。 そうでした。(完璧に意識の外でしたが)Pascalではprocedureのネストが可能で、 呼ばれた側の関数から呼び出し側の関数のローカル変数を参照できるため、 呼び出し側の関数のローカル変数がいつ変更されたのかが見えてしまうわけですね。

>|「元の変数を参照 >| している」ということを意識する必要がありません。アドレスが渡されると >| いうのは実装上の都合であって、コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 > >とあるように、そもそも単なる変数引数であれば「参照値」自体を意識する >必要はないのではないか、ということです。 話は完全にそれますが、この JavaHouse での記述は誤りですね。 var x:integer; procedure hoge(var a: interger); begin a:=1; a:=a+x; end; x:=10; hoge(x); のように、変数引数が alias となるケースでは、参照渡しの場合と、 call-by-value-result 場合とで結果が異なります。 参照渡し: x=2 call-by-value-result: x=11 参照値であるということを意識しないですむとは限りません。

>これが同じ意味になるのは、pascalにコピーコンストラクタのようなものがないからですよね。もしC++だったら別の意味になってしまいます。 なるほど。それはわかります。 >ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 >従来「値渡し」と呼んでいるものは、たいていの場合スタックにコピーが作られるので「コピー渡し」であると。逆に「参照渡し」と呼んでいるものは「原本渡し」であると。 なんというか憂鬱本の「実体渡し」を彷彿とさせますが… それはさておき。 「変数引数」的なことをやりたいときに、参照渡しだと、実装上面倒なことに なるケースがあるわけです。たとえばJavaでは、素朴なVMでは、ヒープ中の オブジェクトの先頭以外、ポインタが継続して指すことはありませんが、 参照渡しを許すと、ローカル変数やら、オブジェクトのメンバやら、配列の 要素を指すポインタが継続して保持されてしまう。これは、ガベージコレクタの 実装を考えると何かと面倒です。 そのせいかどうかは知りませんが、Javaは変数引数という機能を言語から 捨て去ってしまった。でも、やっぱりそれじゃswap()も作れないし不便だよね、 という時に、call-by-value-resultという実装方法は効果を発揮するわけです。 Pascal的な言語だと、こうやって実装の楽なGCと変数引数が混在できますが、 コピーコンストラクタを好き勝手に書けるC++だと難しそうではあります。 C#では、=でコピーコンストラクタが動くわけではなかったですよね。確か。

>ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 「shallow copy渡し」「deep copy渡し」とか出てきたりして(^-^;)

>| いうのは実装上の都合であって、コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 おお、なるほど！ で書かれても実際にはコピーを渡す、という実装のされ方もありえるわけですね。 メモメモ・・・と。 ただ、その場合でも関数から戻ってきた際のコピー先を引数として渡さなくても、 暗黙的にはスタックとかに積んでおく必要がありそうですね。 >アプリケーションプログラムを書くのなら、なるべく上の方の世界に住んでいたいなあ、 >と私は思うわけでして。 あ、これは私も思います。