K.Maebashi's BBS

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

>| コピーを渡してリターン時に元のところに >| コピーし戻すという実装でも同じ意味になります (これをcall-by-value- >| resultと呼ぶ)。 ここにだけ反応。 これが同じ意味になるのは、pascalにコピーコンストラクタのようなものがないからですよね。もしC++だったら別の意味になってしまいます。 ということで、「コピー渡し」「原本渡し」という言葉を考えてみました。 従来「値渡し」と呼んでいるものは、たいていの場合スタックにコピーが作られるので「コピー渡し」であると。逆に「参照渡し」と呼んでいるものは「原本渡し」であると。 コピーを作るかどうかが意味論上、重要な違いをもつ場合もありますので、 こういう区別って大事だと思うんですが。

>> うーん、これが関数の引数についてであれば、「参照渡し」はあくまで >> 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは >> 実装に過度に踏み込んでいる気もします。 >なるほど。ポインタ値ならぬ、「参照値」を引き出した後のことは実装任せと >いうことですね。 ええ、すみません、リンクを貼り損ねたおかげで誤解させてしまったようです。 私が言いたかったのは、貼りなおしたリンク先に http://java-house.jp/ml/archive/j-h-b/028784.html#body | Pascalなどでは、(C系と違って)aの参照と | しての値(アドレス)をどこか他のところへ代入することはできませから、aと | いう参照値の生存範囲はそのスコープ内に限られます。そのような言語では、 | 変数aは呼出し元の変数と「同一物」と考えれば済みます。「元の変数を参照 | している」ということを意識する必要がありません。アドレスが渡されると | いうのは実装上の都合であって、コピーを渡してリターン時に元のところに | コピーし戻すという実装でも同じ意味になります (これをcall-by-value- | resultと呼ぶ)。 とあるように、そもそも単なる変数引数であれば「参照値」自体を意識する 必要はないのではないか、ということです。 まあ、Pascalはともかく少なくともC++では、そういう引数渡しを言語自体が 「参照渡し」と呼んでいるので、ここまで言ってしまうのも問題かもしれませんが、 アプリケーションプログラムを書くのなら、なるべく上の方の世界に住んでいたいなあ、 と私は思うわけでして。

>うーん、これが関数の引数についてであれば、「参照渡し」はあくまで >「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは >実装に過度に踏み込んでいる気もします。 > >参考リンク： >http://java-house.jp/ml/archive/j-h-b/028784.html#body すみません、リンクURL貼り損ねました。正しくはこっちです。 http://java-house.jp/ml/archive/j-h-b/028873.html#body

> 「JVMはアドレスを使うとは限らんからJavaにはポインタはないのだ」 > という批判からすれば、2段階離れたところにいるわけです。 了解です。 > でもそれを前提にしてくれるな、というのが私の言いたかったことなのでした。 Javaプログラマ達さんのいう「ポインタ」の概念が、 K&Rの「ポインタは、他の変数のアドレスを内容とする変数であり」(p.114)の文章を 前提としているなら「Javaにはポインタがない」という主張はあり得ますね。 ただし、その場合は引用なりすべきだと思います。 > うーん、これが関数の引数についてであれば、「参照渡し」はあくまで > 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは > 実装に過度に踏み込んでいる気もします。 なるほど。ポインタ値ならぬ、「参照値」を引き出した後のことは実装任せということですね。 # 私はまだまだこの辺りの線引きがヘタだなぁ・・・

>JVMの仕様書 → 参照はポインタ > >K&R → ポインタはアドレス > >ゆえに参照はアドレス > > >・・・と3段論法にしてしまいますか(^-^;) 私が言っているのは、 ・Javaのポインタ(参照)は「C/C++の」ポインタとは違う(ところがある) 　→Java謎+落とし穴～ 2.1.2「C/C++のポインタとJavaのポインタとの違い」 ・Cのポインタは、必ずしも(生)アドレスである必要はない 　→ポインタ完全制覇 2.9 「言語仕様と実装について」 ということなので、村山さんが言うところの、 「JVMはアドレスを使うとは限らんからJavaにはポインタはないのだ」 という批判からすれば、2段階離れたところにいるわけです。 まあ、村山さんの批判対象は、きっと私以外の誰かなのでしょうが。 >↑は冗談としても、ポインタというのはすべからく「データの在り処を >指し示すもの」でしかないわけで、Javaの「参照」もC言語のような >ポインタではないという風に結論付けてもポインタというのはプログラミング >言語にはついて回る概念だと考えています。 そう思います。ただ、もしポインタについて「データの在り処を指し示すもの」 という定義をとらず、「ポインタとはアドレスのことなのだ」という定義の上で 話すのであれば、「Javaにはポインタがない」という主張はあり得ます (そういうこともJava謎+落とし穴～には書きました)。 でもそれを前提にしてくれるな、というのが私の言いたかったことなのでした。 >　参照渡しについて、値渡しとの違いを説明するときにも「データの在り処を >渡す」としか説明できないのであれば、それはやはりポインタでしかないと思います。 うーん、これが関数の引数についてであれば、「参照渡し」はあくまで 「変数引数」の実装手段に過ぎない、と考えれば、これをそこまで言ってしまうのは 実装に過度に踏み込んでいる気もします。 参考リンク： http://java-house.jp/ml/archive/j-h-b/028784.html#body

JVMの仕様書 → 参照はポインタ K&R → ポインタはアドレス ゆえに参照はアドレス ・・・と3段論法にしてしまいますか(^-^;) ↑は冗談としても、ポインタというのはすべからく「データの在り処を指し示すもの」でしかないわけで、Javaの「参照」もC言語のようなポインタではないという風に結論付けてもポインタというのはプログラミング言語にはついて回る概念だと考えています。 　それがスタックデータへのポインタであれば「スタックポインタ」ですし、インストラクションデータへのポインタであれば「インストラクションポインタ」でしょう。 　参照渡しについて、値渡しとの違いを説明するときにも「データの在り処を渡す」としか説明できないのであれば、それはやはりポインタでしかないと思います。 　オライリー本では「参照型はオブジェクトへのハンドル」と説明していますが、仮にハンドラが存在したとしても最終的にはデータの在り処を知る必要が出てきますよね。 # ついでに「C言語で言うとポインタと考えられるでしょう」とも書いてあります。:-)