なぜポインタで引っかかる人が多いのか

1 名前：デフォルトの名無しさん [2010/06/30(水) 10:22:47 ] なぜポインタで引っかかる人が多いのか 引っかかる人は何に困惑しているのか 159 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 01:30:09 ] char * p 「char型」の「ポインタ（*）」の「変数p」と言った方がいいかな。 160 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 01:41:40 ] *pの型がcharとかは関係なくて char *p;で宣言される変数はp てだけだろ。 *pは宣言されてない。 配列とかでも同じだからなぁ。 特に分かりづらいと思ったことなかった。 161 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 03:57:28 ] 幅WID, 高さHEIのint型の二次元配列arrayを動的に確保したい。 １）arrayの宣言文を書け。 ２）arrayのメモリ確保文を警告レベル最大でも警告が出ないように書け。 ３）arrayの要素アクセス方法、具体的にはarray中の横からw番目、縦にh番目の要素に0を代入する文を書け。 162 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 06:43:49 ] >>159 char*型の変数pでいいよ。 変数名取り除いたのが型の名前だし。 >>161 とりあえずC99禁止しようか。 163 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 07:37:57 ] >161 二次元配列ってなんだ 配列の配列か 一次元的に取られたメモリを工夫して二次元的に扱える形にしろというのか 一次元的に取られたメモリを工夫して三次元的に扱える形にしろ ただし、外側から縦、横、奥を表すとし、メモリの確保は1回で実行せよ また、型は適当なものをtypedefし、type_t型として作成せよ ただし、縦、横、奥は実行時に与えられ、特定のtype_t型に依存するコードは書いてはならない 縦、横、奥はsize_t型を仮定してよいものとする 全ての縦、全ての横、全ての奥のアドレスに対してそのアドレスがそのアドレス以外のものと異なるようにせよ 全ての縦、全ての横、全ての奥の要素に対して任意の値を代入し不正なメモリ書き換えが行われないようにせよ メモリの確保には標準関数のvoid *malloc(size_t)を使用せよ ここで、言語仕様はC89またはC90を仮定してよいものとする ただし、コンパイラの拡張を使用することを禁止する 例 : type_t ***array3; array3 = alloc3(h, w, d); array3[h][w][d] = val; 164 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 08:05:39 ] 前の問題の答も出さずに勝手な問題積み上げてバカじゃないの 165 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 11:18:28 ] スレタイとは何の関係もない話題になった。 166 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 15:19:30 ] *********************************************p 167 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 16:37:36 ] *は2つあれば十分 3つ以上使うコードがあっても、void**とキャストを使うコードに変換できる 168 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 16:46:54 ] 変換できることに意味はないな。適当にtypedefし直せば充分。 169 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 16:57:39 ] バイナリエディタで機械語書かせれば一発で理解できると思うんだ 170 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 17:15:05 ] 誰も>>161には答えられない、と。 171 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 17:21:17 ] 興味が無ければ答えない。当たり前だと思うが。 172 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 17:24:00 ] 今まさに仕事でその手のコードを書いているからめんどくさいw CPUとGPUの違いやsimdの演算効率の違いを考慮して、 AofSとSofAを切り替えたりxyzの順序を変えたりの詰め替えばっかりw 173 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 18:09:33 ] >>170 配列へのポインタでいいのか？ 174 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 18:32:08 ] >>161 1) int *array; 2) array = (int*) malloc(sizeof(int) * WID * HEI); 3) array[h * WID + w] = 0; Java使いでちゃんとしたCのコードなんか書いたことないんだけど、 これでいいのかな？このスレにいる詳しい人添削頼む。 あと>>163も同じように処理しちゃまずいのかな。 175 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 18:52:55 ] >>174 2次元配列と書いてるから、array[WID][HEI}の形にしないと駄目だろうね >>161の条件だと↓でもよさそうだけど、>>163はひと手間かけないといけない int (*array)[HEI] = (int (*)[HEI])malloc(sizeof(int) * WID * HEI); 176 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 18:56:41 ] 一回でメモリ確保せよとはあるけど必要充分にとは書いてないから、 3次元分のメモリとポインタ分のメモリを確保してポインタの配列をこさえればいいんだけどね。 177 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 22:16:21 ] >>163 >ただし、縦、横、奥は実行時に与えられ、特定のtype_t型に依存するコードは書いてはならない これは↓がだめだという意味？ typedef char (*type_t)[w][d]; type_t array = (type_t)malloc(sizeof(int) * h * w * d); 178 名前：177 mailto:sage [2010/07/05(月) 22:17:04 ] 1行目 typedef int (*type_t)[w][d]; ね。 179 名前：デフォルトの名無しさん mailto:sage [2010/07/05(月) 22:27:24 ] typedefしなくていいのなら、 for文で回しながらmallocして、 for文で回しながらfreeすれば出来そうだけど。 (そこまでするんならいっそ１次元でとって、添え字演算したほうがすっきりしそうだが・・・) >>163 は出来るのかね。 180 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 02:01:16 ] kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/10787.txt 自分で書いていて途中で嫌になってきた typedefを使わないとほとんど読めないプログラムになってしまうのが ポインタの問題だな 関数へのポインタの配列へのポインタを返す関数 (関数は配列を返す事ができないので配列へのポインタで返す) でも無駄な事を一段やってるような気がするな 配列だと分かっているんだから配列を変えそうとせず、ポインタで配列の 先頭アドレスを返せば簡単になるような気もする 181 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 02:16:07 ] いや違うかこれ以上簡単にならんな 関数は配列を返す事が出来ないんだから、配列へのポインタを 返すと書かなければならない 本当はそうではないのだが、Cの文法がそう書く事を許さない仕様に なっている こういう場合は関数宣言の方を変えて、配列を返すのではなく関数への ポインタのポインタを返すと書けば簡単になるだろう 但しそう書くとプログラムが何をやっているのかますます不明瞭になり、 ほとんど読み解く事が困難になってしまう 182 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 02:20:23 ] kansai2channeler.hp.infoseek.co.jp/cgi-bin/joyful/img/10788.txt こんな感じ これなら一段間接参照が減る さて寝よう 183 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 08:36:52 ] array[h * WID + w]でいいよ ひとつ言えることは ポインタで引っかかる人は、文法や型にこだわる 問題を出されると出題者に盲従する傾向がある だったら、文法や型や規格書などに従うのを一度やめてしまえばいい たとえばアセンブラを使ってみるとか 184 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 10:38:36 ] それでいいなら、int array[W][H];も必要ないね 185 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 10:46:20 ] [W][H] じゃなくて [H][W] だというところには誰も突っ込まないんだなw 186 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 10:57:25 ] 言いたいことそんな所じゃないだろうからな。 187 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 10:58:23 ] メモリのスキャン方向が変わるから実行速度等に影響が出るんだが 188 名前：184 mailto:sage [2010/07/06(火) 11:56:51 ] >>175から持ってきて、あんまり考えずに成形しただけだから気にするな >array[h * WID + w]でいいよ　だけだったら異論はないよ あとあと、楽とわかってるから静的に2次元配列として宣言するんだよね 動的確保でも、その楽にする方法があるから、(言い方を借りれば)文法にこだわるんじゃないか まぁ、これも>問題を〜の1文がなければ、そうですねって話だけど 189 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 11:57:59 ] >>79 俺と全く同じ奴がいる・・・ 190 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 12:33:04 ] >>184 array[WID][HEI] と array[h * WID + w] は等価ではない 191 名前：184 mailto:sage [2010/07/06(火) 12:51:07 ] >>190 なぜ、俺にこのタイミングでレスするんだ 安価は>>175にしてくれよな 192 名前：デフォルトの名無しさん [2010/07/06(火) 12:56:11 ] アホ曝しage 184 デフォルトの名無しさん [sage] 2010/07/06(火) 10:38:36 ID: Be:     それでいいなら、int array[W][H];も必要ないね 193 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 14:40:57 ] >>183 良くない。 array[h][w]という表記ができない言語（例えばアセンブラ）ならそれでもいいが、 言語仕様で出来るのにやらないと、後から読んだ者を混乱させる。 理由があってわざとやらないのか、書いた奴が知らなかっただけなのか判断つかないからな。 それに、hとかwとかなら array[h*WID+w]でもarray[h][w]でも大差ないが、もっと複雑な式に なった時に、[h][w]形式の方が断然読み易くなる。 ぶっちゃけ、二次元ポインタを使いこなせない奴の言い訳にしか見えない。 194 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 15:49:07 ] どうでもいい。 個人的にはベタバッファにポインタアクセスのが分かりやすいし、使いやすい。 C++は知らんがCなら慣れの問題。 195 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 15:58:19 ] array[i][j] と記述したくなるのは、ベクトルやマトリックス周辺だけかな。 数式をそのままに近い形式で記述したい　という意図だけどね 196 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 16:09:18 ] 結果あわせるだけならどっちでもいいんだけれども 配列のアライメントや入れ替えがあるから、用途によるよね 197 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 16:42:13 ] >>190 どう等価じゃないんですか？ 198 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 16:56:35 ] array[4][5]とarray[5][4]は違うと言っている。 199 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 18:54:32 ] こういう書き方はどうか？(長文失礼) ・char , int は型である。 ・Tが型ならば、T[N]は型である。(Tの配列と解釈する) ・Tが型ならば、$Tは型である。(Tへのポインタと解釈する) ・T,U1,U2,…,Umが型ならば、T(U1,U2,…,Um)という記号列は型である。(関数と解釈する) ・宣言方法は「T a；」とする。 具体例(カッコは適宜省略)　　C言語での表記法 　↓　　　　　　　　　　　　　　　　　↓ int a；　　　　　　　　　　( int a；という意味) int[N] a；　　　　　　　　( int a[N]；という意味) (int[w])[h] a；　　　　　 ( int a[h][w]；という意味。wとhは逆になる) $int a；　　　　　　　　　( int* a； ) int(char) func；　　　　 ( int func(char)； ) $($int) a；　　　　　　　　( int** a； ) ($int)[N] a；　　　　　　( int* a[N]； ) $(int[N]) a；　　　　　　( int (*a)[N]； ) $(int(char)) f；　　　　　( int (*f )(char)； ) ($int)(char) f；　　　　　( int* f (char)； ) int($char) f；　　　　　　( int f (char*)； ) ($(int(char)))[N] f；　　 ( int (*f [N])(char)； ) ($$(int(char)))[N] f；　　( int (**f [N])(char)； ) $(($(int(char)))[N]) f；　( int (*(*f )[N])(char)； ) 200 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:03:33 ] ご苦労さん 201 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:14:30 ] >>193 記述の問題ならマクロ導入すりゃいいでしょう 202 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:17:35 ] まあな。ｗ 203 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:33:38 ] ポインタに1足したら、2byteとか4byteとか進む? ポインタってアドレスなんだろ? そんなもん1進むに決まってるんじゃないのか? 204 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:41:18 ] オブジェクト（要するに型）のサイズ分進む。 sizeof演算子で進む量を得ることが出来る。 205 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 19:58:50 ] >>197 判ってて聞いてるんだろうけど array[h * WID + w] と array[w][h] はポイントしているアドレスが違う array[h * WID + w] と array[h][w] が同じ場所を指さないと 共同開発してる仲間に迷惑だろ？ そんなことも知らないからポインタスレに来てるんですねわかります 206 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 20:21:03 ] 前者は連続した領域にmallocすることが求められるが、 後者は離れた領域にmallocしても一向にかまわない。 207 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 20:22:13 ] そろそろ>>163の見本お願いします 208 名前：163 mailto:sage [2010/07/06(火) 20:58:16 ] >>207 まあ、あせるな みんな、なかなかいい線いってるよ もう少し検討が深まるのを待とう 209 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 21:32:28 ] >>208 これはだめなの → >>177 C89ならw,dが変数でも通ったけど。 210 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 21:41:09 ] >209 >208ではありませんが、コンパイラとコンパイルオプションを示してみてください また、可能であればコンパイラのバージョンも示してみてください 211 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:00:20 ] >>210 PC@Test> gcc --version gcc.exe (GCC) 3.4.5 (mingw special) Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. PC@Test> gcc -Wall -pedantic -std=c89 Test6.c Test6.c:14: warning: ISO C90 forbids variable-size array `type_t' Test6.c:14: error: variable-size type declared outside of any function Test6.c:14: warning: ISO C90 forbids variable-size array `type_t' Test6.c:14: error: variable-size type declared outside of any function ごめん、今やったら通らんわ。 212 名前：221 mailto:sage [2010/07/06(火) 22:01:09 ] 昨日、下記のソースをいじってら通ったんでC89ならOKなんだと思ってた。 昨日の試行錯誤の過程で勘違いした模様。 #include <stdio.h> #include <stdlib.h> #define MODE (0) #if MODE == 0 int w = 10; int d = 20; #elif MODE == 1 const int w = 10; const int d = 20; #elif MODE == 2 #define w (10) #define d (20) #endif typedef char (*type_t)[w][d]; int main(void) { int h = 30; type_t array = (type_t)malloc(sizeof(char) * h * w * d); printf("%d\n",((int)&array[0][0][1])-((int)array)); printf("%d\n",((int)&array[0][1][0])-((int)array)); printf("%d\n",((int)&array[1][0][0])-((int)array)); free(array); return 0; } 213 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:08:40 ] てか何が出来たら「三次元的に扱え」たコトになるのよ？ 条件が色々付いてるけど、根本的な要求が分からん 214 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:11:01 ] 下記のポンタ何を指すが書きなさい 15秒以内の回答できて小学1年レベルらしい int (*a)[N]； int (*f )(char)； int (*f [N])(char)； int (**f [N])(char)； int (*(*f )[N])(char)； 215 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:15:02 ] >>214 日本人ではないな？ だからどう、ということもないが 216 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:51:32 ] m行n列の二次元配列をメモリ上に表現する場合 1 サイズm*nの一次元配列として確保 2 サイズmのポインタの配列とサイズnの一次元配列m個 1の利点 ポインタの配列分メモリが必要無い 2の利点 列を削除追加できる 2は多段のポインタなので 普通の二次元配列として扱うと遅い 中継用のポインタ使う必要があるので可読性は低い 217 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:53:54 ] 2 はargvですね 218 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 22:57:59 ] 小学生すごいな、即答出来ても15秒で書けないな 219 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 23:01:51 ] >>218 小学生でも朝鮮・中華の小学生だから 220 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 23:07:14 ] >>214 上から順に 行列の行単位で動くポインタ 関数ポインタ ポインタ配列 ポインタ配列 行列の行単位で動くポインタ 行列やポインタ配列の要素の型、つまりテンプレート引数に相当する部分は気にしない。 昔のJavaはそうだったというかむしろシンプルでわかりやすいとか言われて普及した。 221 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 23:28:34 ] >>216 >2は多段のポインタなので >普通の二次元配列として扱うと遅い これマジ？ ケースバイケースだろうけど、乗算して加算して参照より、 参照してさらに参照のが速いのかと思ってた。 222 名前：デフォルトの名無しさん mailto:sage [2010/07/06(火) 23:43:30 ] >>221 F-22とスピットファイアくらい違う 223 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:00:13 ] >>214 ポンタはわからねえな 224 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:08:27 ] >>223 上から順に 　ポインタ 　ポインタ 　配列 　配列 　ポインタ なのは分かるよね。 後は、ポインタだったらポインタの部分を削除して型を見て、 配列だったら配列の部部を削除して型を見る。 そうすると、 　配列のポインタ 　関数のポインタ 　関数のポインタの配列 　関数のポインタのポインタの配列 　関数のポインタの配列のポインタ となる。 合ってる？ 225 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:11:02 ] >>180の int (*((*func(void))[]))(void) これ鬼みたいだな しかしプログラムを読むと大して難しい事をやっているわけではない Cの宣言はどうしてこんなに難解なのだろうか 226 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:12:49 ] >>222 どっちが速いのかすら分からん。 あー、もしかしてキャッシュに乗らない？ あんまりその世界で生きてないんで どう動くのかサッパリ。 227 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:17:46 ] >>225 アセンブリをやれば簡単に読めるようになる 228 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:33:24 ] int (*((*func(void))[]))(void) は保育園レベルでちゅよ この程度すぐに解らんと保育園レベル未満の国語力ってことでちゅ 229 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 00:44:13 ] >>225 リンク先は見てないけど、そんなに難解？ ちゃんと()付いてるし。 まず一見してfunc(void)な関数の宣言だろ。 *付いてるから返値はポインタ。 さらに[]なんで配列のポインタ。 次の*で、ポインタの配列のポインタ。 で、最後にint ()(void)なんで、つまりこの宣言は そういう関数へのポインタの配列のポインタを返す、引数voidな関数funcの宣言。 長々書いて違ってたら、凄い恥ずかしいんだが、どないだろ？ 230 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 01:14:43 ] >>229 >長々書いて違ってたら、凄い恥ずかしいんだが、どないだろ？ どのように解析するか自信ないのか？ コンピラー(C言語)の構文解析ルールをよく知らないってこと？ コンピラーはfunc(void)が関数の宣言ってどうしてそう判断するん？ 職業PGにとって構文解析って基礎中の基礎事項で学校で当然習っているじゃないの それすら知らないのに職業PGやってるって人居ないよね 趣味PGなら自分が必要と感じたら勉強してみるか程度で良いけど 231 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 01:26:06 ] >>221 キャッシュへのプリロードするのに間接参照だと予測不能。 232 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 01:41:39 ] 書き方を修正。「$T」じゃなくて「T$」に変えてみた。 ・char , int は型である。 ・Tが型ならば、T[N]は型である。(Tの配列と解釈する) ・Tが型ならば、T$は型である。(Tへのポインタと解釈する) ・T,U1,U2,…,Umが型ならば、T(U1,U2,…,Um)という記号列は型である。(関数と解釈する) ・宣言方法は「T a；」とする。 233 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 01:46:37 ] 以下、具体例。(長文失礼します) 具体例(カッコは適宜省略)　 C言語での表記法 　↓　　　　　　　　　　　　　　　 ↓ int$ a；　　　　　　　　　　( int* a； ) (int$)$ a；　　　　　　　　( int** a； ) (int$)[N] a；　　　　　　　( int* a[N]； ) (int[N])$ a；　　　　　　　( int (*a)[N]； ) (int(char))$ f；　　　　　( int (*f )(char)； ) (int$)(char) f；　　　　　( int* f (char)； ) int(char$) f；　　　　　　( int f (char*)； ) ((int(char))$)[N] f；　　 ( int (*f [N])(char)； ) ((int(char))$$)[N] f；　　( int (**f [N])(char)； ) (((int(char))$)[N])$ f；　( int (*(*f )[N])(char)； ) $が入ってないものは>>199と 全く同じになるので省略しました。 234 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 02:27:17 ] >>232の定義に ・Tが型ならば、T[ ]は型である。 をつけ加えると、>>180の ＞int (*((*func(void))[]))(void) これも232の形式で書けて ((((int(void))$)[ ])$)(void) func； となります。 また、T[N]$ と書いたとき、これを(T[N])$と読むことは出来ても T([N]$)と読むことは出来ないし、T$$とかT$[N]なども同様のことが 言えます。よって、ある程度カッコを省略できて、結局、 次のように表記できます。 ((int(void))$[ ]$)(void) func； 235 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 04:45:01 ] 関数ポインタ関連の表記は参考サイトや本を読みながらじゃないと読めん あれ何とかならんかったんか 236 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 04:58:29 ] typedef すれば大抵解決 237 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 07:18:47 ] >>230 煽りか本気か知らんが、職業PGに夢見すぎ 238 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 07:30:54 ] 関数ポインタが読みにくいという事はCでC++モドキのプログラムを バリバリ書くのは不可能に近いって事ですね それか無駄な時間を多量に要するか 239 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 11:32:30 ] >>238 他の言語に比べて積極的な気持ちになりにくいかな？ ただ、昔読んだテキストエディタのソースでは、入力文字のアスキーコードを引数にして各入力処理関数に飛ぶように、関数ポインタの配列が使われていて感動した。 日本語処理をさせるのは難しそうだけど。 240 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 13:03:10 ] perlよりマシだな 241 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 13:53:02 ] エセクラスならgtk2が頑張ってなかったっけ？ 242 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 14:11:48 ] gtk++/gtkmm よりも gtk の方が出来が良いという 243 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 17:04:48 ] >>229 あってますね 規則に従って変換したら、>>234になったｗ int(void)*[]* (void) func 244 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 18:29:24 ] >>235 >>232-234の書き方だと、日本語の語順そのままで 宣言できます。たとえば、 ・(戻り値int，引数charの関数)へのポインタ が欲しかったら、そのまま (int(char))$ pfunc； と書けます。>>180の ＞int (*((*func(void))[]))(void) だったら、これを日本語読みすると (((戻り値int，引数voidの関数)へのポインタ)の配列)へのポインタ) を戻り値とする、引数voidの関数 となるので、この語順そのままに (int(void))$[]$ (void) func； と書けます。 245 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 21:45:29 ] >>244 君は度々出て来るようだけど、結局主張は何？ 246 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:04:51 ] >>245 >>232-234の書き方なら、C言語よりも ずっと読みやすい表記法で関数ポインタが表記できる、 ということです。 247 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:05:17 ] >>245 型の表記は関数型言語スタイルがいいですね、ということです 248 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:08:02 ] typedef の方が判りやすいよ 249 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:29:47 ] >>248 typedefの方法は>>232-234と同じようなもんです。 あなたにとってtypedefが分かりやすいなら、 ほぼ同程度に232-234も分かりやすいことになります。 たとえば、C言語で typedef int (*PFUNC)(char)； と書いておけば、もはや PFUNC pfunc； と書くだけで「(戻り値int，引数charの関数)へのポインタ」が 宣言できるようになりますが、このときの「PFUNC」という記号列は、 >>232-234で言うところの「(int(char))$」という記号列と 全く同じ役割をしています。つまり Func ≡ (int(char))$ ということです(誤解を招きそうな式ですが)。 別の言い方をすれば、「PFUNC pfunc；」と同じ語順の宣言が 最初から可能なのが>>232-234ということです。 250 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:39:24 ] ou.... ×　Func ≡ (int(char))$ ○　PFUNC ≡ (int(char))$ 251 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:41:50 ] んなことは言われんでもわかっとる     (int(char))$ よりも     PFUNC の方が判りやすいだろって話 252 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:52:58 ] >>246 よく分かった。 新しい言語、文法を語りたいだけなら、引っ込んで黙れ。 そういうスレがあるし、そっち行け。 ポインタが分かりづらいのはCの文法が悪いから、とか それなりのコト言うのかと思えば、ただのアホかよ。 253 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:55:49 ] >>251 どうですかね。「PFUNC」と書いてしまうと、中身が 見えなくなって抽象的になってしまう弊害があります。 (int(char))$だったら、そのまま読めます。 しかも日本語の語順のまま読めます。 僕にとってはint(char)$ の方が読みやすいです。 ただし、PFUNCという記号列を日常的に typedef int (*PFUNC)(char)； の意味で使っている人だったら、その人にとっては PFUNCという記号列は全く抽象的では無いわけですから、 その人にとっては、PFUNCの方が読みやすいかもしれません。 254 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 22:59:14 ] ひとつのプロジェクトに 独自のGC、newが複数混在してると 最高にわかり辛い それぞれが読みやすいものでもな 255 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 23:02:06 ] >>252 ＞ポインタが分かりづらいのはCの文法が悪いから、とか ＞それなりのコト言うのかと思えば、ただのアホかよ。 え？それって同じことですよね？ 「ポインタが分かりづらいのはCの文法が悪いからだ！」 という意見を煮詰めて行ったら、どのみち 「では、文法をこのように変えたらどうだろうか(例えば232-234のように)」 という意見にならざるを得ないでしょ？ 256 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 23:09:36 ] // それぞれが読みやすい typedef int (*PFUNC)(char); typedef PFUNC T[N]; // 混在すると分かり辛い typedef int (*T[N])(char); 257 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 23:48:51 ] 混在してると分かりづらくなる文法が悪い？どっちが悪い？混在が悪い？文法が悪い？ 258 名前：デフォルトの名無しさん mailto:sage [2010/07/07(水) 23:58:37 ] >>255 ならんよ。 だってその表記を見ても、Cのポインタが 理解できるようになりそうにないもの。 言語変えて済む話ならポインタのない言語を選べばいい。 259 名前：デフォルトの名無しさん mailto:sage [2010/07/08(木) 00:17:00 ] >>258 言ってることが矛盾してませんか？あなたにとって、 ＞ポインタが分かりづらいのはCの文法が悪いから、とか ↑この意見は"それなりの意見"なんですよね？(>>252にそう書いてあるし。) でも、これは「Cの文法を改良すればポインタが分かるようになる」と 言っているのと同じことですよ。 一方であなたは ＞言語変えて済む話ならポインタのない言語を選べばいい。 と言ってますから、結局あなたは 「Cの文法を改良すればポインタが分かるようになる」 という意見を全否定しているわけです。つまり、あなたは ＞ポインタが分かりづらいのはCの文法が悪いから、とか ↑この意見を"それなりの意見"としつつも全否定しているわけです。

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef