int *p ; // intの値へのポインタ変数の宣言 p ; // intの値の変数へのポインタ *p ; // int の値 int n ; // intの値の変数の宣言 n ; // intの値 &n ; // intの値の変数へのポインタ ↑これって不自然じゃない? どうして↓のようにしなかったの? int $p ; // intの値へのポインタ変数の宣言 $p ; // intの値の変数へのポインタ p ; // int の値 int n ; // intの値の変数の宣言 n ; // intの値 $n ; // intの値の変数へのポインタ
int *p ; // intの値へのポインタ変数の宣言 int n ; // intの値の変数の宣言 p = &n ; // intの値へのポインタの代入 *p = n ; // intの値の代入 というよりも、 int $p ; // intの値へのポインタ変数の宣言 int n ; // intの値の変数の宣言 $p = $n ; // intの値へのポインタの代入 p = n ; // intの値の代入 のほうが、すっきりすると思うのだけど。
3 :
デフォルトの名無しさん :2005/05/07(土) 07:47:42
終了
4 :
デフォルトの名無しさん :2005/05/07(土) 08:01:33
根源的に無能
6 :
デフォルトの名無しさん :2005/05/07(土) 08:10:23
&n はポインタじゃなくて、int nのアドレスでしょ。 Perl風に$でアドレス表すことにするなら、 int $p; っていう宣言はおかしい。pは使うときは普通に$つけずに普通にpで使うんだから、宣言は int p; でしょ。ということは、普通のintと同じことになるから、型に厳しいCとしては、ポインタ型っていうのを別に作ったんじゃないの、たぶん
そこで Pascal 風文法
#define S(v) &v int p; // intの値の変数の宣言 S(p); // intの値の変数へのポインタ p; // int の値 int n; // intの値の変数の宣言 n; // intの値 S(n); // intの値の変数へのポインタ
仮引数とか左辺値の時に困らんか?
参照(References) 参照とはある変数の別名を持った変数であり,次の構文で宣言される. データ型& 参照する名前 = 変数名; と記述する.例えば, int n = 44; int& rn = n; と宣言すると,rnはnの参照である.素人の言葉で説明すると,参照とは芸名みたいなもので, 名前は違うけれど,名前が指している人は同じ人ということである.
おっと間違い
13 :
デフォルトの名無しさん :2005/05/07(土) 08:34:54
アドレス演算とかどうすんのさ
15 :
きそちしきだから、ほかのひとにじまんしちゃだめだよ :2005/05/07(土) 08:54:01
int *P; // intの値へのポインタ変数の宣言 int& p = *P; // intの値の変数の宣言 S(p); // intの値の変数へのポインタ p; // int の値 int n; // intの値の変数の宣言 n; // intの値 S(n); // intの値の変数へのポインタ S(p) = S(n) ; // intの値へのポインタへ、intの値へのポインタを代入 // &p=&n つまり P = &n と同じ p = n ; // intの値の代入 // *P = n と同じ
>>13 IPアドレスにマーキングしても、だめだよ
■■■■ スレ終焉 ■■■■
18 :
デフォルトの名無しさん :2005/05/07(土) 09:24:16
元々アセンブラで一般的なレジスタによるアドレッシングの方法がポインタの概念だよ。 だから、そういう観点からいうとCのポインタは極自然。 例えば、 int* m = pDest; int* n = pSrc; *m++ = *n++; を86でかけば、 mov edi, dword ptr [pDest] ;アドレスを ediレジスタにロード mov esi, dword ptr [pSrc] ;アドレスを esiレジスタにロード mov eax, dword ptr [esi] ; *m を eax にロード mov dword ptr [edi], eax ; *n にeax をストア inc esi ;m++ inc edi ;n++ みたいな。
19 :
デフォルトの名無しさん :2005/05/07(土) 10:49:15
>inc esi ;m++ >inc edi ;n++ ?? add esi,4 ; sizeof int add edi,4
20 :
デフォルトの名無しさん :2005/05/07(土) 11:48:28
既存の言語の仕様が気に食わなければ、自分で言語を作れ! ・・・って、perlの作者の人が言ってなかったか?
21 :
デフォルトの名無しさん :2005/05/07(土) 11:55:00
>>20 まったくそういうことだな。
今の政治が気に食わないなら自分が総理大臣になれっていう
捨て台詞を吐く友人がむかつく。
>>15 S(p) = S(n) ; // pのアドレスをnのアドレスで上書き
配列をポインタみたく扱うようなもの。
pがリファレンスじゃなかったら、メモリー回収できなくなるでしょ。
うん、最初っから判ってる。
変な拘束ゲーム始めた
>>1 は
気付かなかったみたいだけどw
24 :
ウンコ :2005/05/07(土) 13:51:53
/** Sample.cpp * コンパイル方法: * gcc -E Sample.cpp | sed -e 's!&\*!!g' > Sample.i.cpp * ~~~~~~~~~~~~~~~~~外部プリプロセス処理 * gcc -o Sample.exe Sample.i.cpp */ #include <stdio.h> #define S(v) &v // 下記置換はC pre processorでは不可能なので、外部プリプロセスで処理する //#define &* int main(int argc, char*argv[], char*envp) { int v = 1; // intの変数宣言 int *P; // intへのポインタ変数宣言 P = &v; // intのポインタ変数へ、intの変数のアドレスを代入 #define p *P //S(p); // intの変数へのポインタ //p; // intの値 int n = 2; // intの変数宣言 //n; // intの値 //S(n); // intの変数へのポインタ S(p) = S(n); // intのポインタ変数に、intの変数のアドレスを代入 // 外部プリプロセス処理の結果、 // &*P = &n は P = &n と同じ p = n ; // intの値の代入 // *P = n つまり v = n と同じ return 0; }
つか、どうでもいいが int main(); でいいよな
つかCだっつってんだからC++出すな。
ぷ
よく見る間違ったmainの数々 void main(void) void main(int argc, char *argv[]) int main(int argc, char *argv[]) 正式な形式はこうだ。 int main(int argc, char **argv, char **envp)
29 :
デフォルトの名無しさん :2005/05/07(土) 17:21:56
>>28 職業的プログラマーの俺に言わせれば、
動けば良いのだよ、なんであっても・・・
つーか間違ってないし
31 :
デフォルトの名無しさん :2005/05/07(土) 17:28:57
コンパイル後はスタートアップルーチンからのmain()の呼び出し方法が変わるだけ
32 :
デフォルトの名無しさん :2005/05/07(土) 17:34:56
>>28 どうでもいい。
俺は逆に、コマンドラインパラメータを使わなかったり、戻り値チェックしないなら、
void main( void )
で明示してる(していた)。
33 :
ウンコ :2005/05/07(土) 17:39:26
34 :
デフォルトの名無しさん :2005/05/07(土) 17:48:29
>>28 初心者はそう書きたがるんだけど、
必要ないものは省略するのがCの慣習なのだよ。
35 :
ウンコ :2005/05/07(土) 17:54:05
誰もそんなとこ気にしねぇ〜よ。 Cのスタートアップルーチンは、 単に _mainラベルを C言語呼び出し規約で呼び出すだけだからな。 C++と違って、なんでもいいんだよ。 残念
void 姪(void)
37 :
デフォルトの名無しさん :2005/05/07(土) 18:08:19
リンカ/ローダは _main識別子を捜すから、 C言語上は main 識別子を必ず使えよアフォ。 マクロ定義してからヤレ。 #define 姪 main #define 切腹 exit
38 :
1 :2005/05/07(土) 18:19:24
色々釣れたわけだが、 C言語のポインタは、変数の型の一つに過ぎない というまっとうなことを言えたのは、誰もいないな。 int *p ; のように書くからいけないのであって、 typdef int* ptr_int ; ptr_int p と書けばいい。 int* p, q ; なんて罠があるから、typedefすべし。 ついでにマクロも #define REF(x) (*x) #define PTR(x) (&x) で、↓のようになるわけだ。 ptr_int p ; // int値へのポインタ値の変数の宣言 p ; // int値の変数へのポインタ値 REF(p) ; // int値の変数へのポインタ値が指す先のint値 int n ; // int値の変数の宣言 n ; // int値 PTR(n) ; // int値の変数へのポインタ値 どうだ、スッキリしたろ。
39 :
1 :2005/05/07(土) 18:20:40
すまん。括弧が足りなかった。 #define REF(x) (*(x)) #define PTR(x) (&(x))
プリキュアの白いほうって彼氏いるのかな? 当方28歳なんだけど、告ったらふられるかな?? どう思う???
あたってくだけろ
42 :
デフォルトの名無しさん :2005/05/07(土) 18:49:20
バカじゃねぇの?
>>1-2 見て、池沼だと思った。
やっとポインタ覚えたのねw
で、プログラムはいつ書けるようになる予定?
じゃ、
>>24 が正解、
>>38-39 はルール変更で失格
てことで。
===============終了===============
44 :
デフォルトの名無しさん :2005/05/07(土) 19:10:13
>>38 typedefすりゃいいって、そういう問題じゃないだろ。
45 :
デフォルトの名無しさん :2005/05/07(土) 19:14:46
まあ記号の使いまわしはやめてほしいよな +と++の違い程度ならまだ許せるけど a*b の*は掛け算で、 *bとなったらポインタってのは 納得できないと思うよ そういう仕様 の一言で片付けるには納得しがたい なぜ*という記号をポインタに選んだのか その理由を答えろ!カーニハン!
>>38-39 ・演算子をマクロに置き換えて、あと
・typedef やっと覚えた、
だけだろう。
>typedef int *inp_ptr;
>#define REF(x) (*(x))
ポインタ演算子 '*' → マクロ REF(x)
>#define PTR(x) (&(x))
ポインタ演算子 '&' → マクロ PTR(x)
47 :
デフォルトの名無しさん :2005/05/07(土) 19:20:11
しかし確かに言われてみればそうだよな。 *である必然性はないわな。 #でも$でも@でもいいだろうし。 なぜあえて掛け算記号と重複させたのか?というのは疑問だ。
48 :
デフォルトの名無しさん :2005/05/07(土) 19:25:05
C++/CLIでは、マネージポインタの識別子として^を使うわけだが。 XORかよ!
・ビジネス分野で最も普及した関数型言語APLの演算子は、 普通のKBとフォントじゃ書けないw ・昔の非ASCII文字コードを使ったマシンでは、 演算子にできる文字が極めて少ない (現在の半分くらい。どうしても書けない記号はトライコード(K&R)で書く) ・Smalltalkの演算子もかなり変。 AltoPC上: ↑値 現在: return 値
func1( int *a ) { } func2( int a ) { } hoge() { int *a, b; a = *b; b = &a; func1( *b ); func2( &a ); } のほうが自然だよなあと思う。
まじか
>>45 英語キーボードの*の位置をよく観察すれば答えがわかるはず
っていうか、記号の使いまわしは仕方が無いと思うけどな
とりあえず、C言語では一通りの記号を使いきっているわけだし
しいて言うなら「_」が演算子としては余っているけど、ねぇ?
それは英数字の一部扱いでは。
Cで演算子として使われてない記号は@と$と~と`
>>53 おまえ、カーニハンか? 元気だった?
ところで、&と*が並んでるからとか、そういう理由なのか?
答えろ!カーニハン!
@とかあまってたジャンよ
蟹飯の贋者ですが、
pdp11のアセンブラの
アドレッシングモードの
間接参照の文法からきている...そうです。
The syntax of the address forms is
identical to that in \s8DEC\s10 assemblers, except that ``*'' has
been substituted for ``@''
and ``$'' for ``#''; the \s8UNIX\s10 typing conventions make ``@'' and ``#''
rather inconvenient.
.PP
ttp://cm.bell-labs.com/7thEdMan/vol2/assembler
59 :
デフォルトの名無しさん :2005/05/07(土) 20:47:54
@は、メールアドレスと座標表示用にリザーブ。 ~は、AWK (Aho-Wainberg-Kernighan)で、パターンマッチ用に使用済。 ちゅぅか、'>>'演算子, '<<'演算子の優先順位の設計ミスをなんとかしてほしい。
あと、演算子を議論したい場合は、 最低限「演算子順位文法」とそのパース方法をマスターする 努力をすることw
努力だけでいいのかw
Turbo C 2.0の時に~は塩山市として使った覚えがある…
~はビット反転。
>>63 今思い出したーよ。
皆がその役目を忘れてる
'~'タン、カワイソ
65 :
デフォルトの名無しさん :2005/05/07(土) 22:57:30
~ を使わないCプログラマって…
66 :
デフォルトの名無しさん :2005/05/07(土) 22:59:18
@は演算子として使われているわけじゃないから問題ないよ。
低スキルPGが大はしゃぎだな
a+=b; a-=b; a|=b; a&=b; a==b;//これこそ、真の代入ではなかろうか…
デストラクタの~はどんな扱い?
>>70 a=bの結果をaに代入するってことか。
つまりa=bと同じだな。
>71 C言語にデストラクタなどないw
typedef struct { int i ; } St ; St s, *sp ; sp = &s ; s.i=1 ; sp->i=2 ; (*sp).i=3 ; sp[0].i=4 ;
まぁ、現場ではバグの含有率が一番多いのが、 C言語で書かれたプログラムだ。 いろいろな意味で、一番タチが悪い。
>>75 Source Please !!
VB だって、COBOL だって負けてはないと思うが。
>>75 そうか、むしろJavaとかの方が多い気がする、適当に書いてもそれなりに動くから、かなりフィックスされないバグが多い気がする。
オマエラ変な風に考えすぎ。 int a, *p, **pp; int f(); これで a も *p も **pp も f() もみんな int型。 シンプルだろ。 int *p; は p が intポインタ型という意味じゃなくて *p が int型と読むんだよ。 だから、 int* p; なんてキモい表記はするなよ。
C++はダメでC言語しか語れないキモイ方なんですね
(*printf)("これだけはキモイ");
(*0)[a]
83 :
デフォルトの名無しさん :2005/05/08(日) 19:05:18
Dだとどうなんかなあ?
>>82 似たようなので、構造体の任意のメンバの
先頭からのオフセットをコンパイル時に数値で得る方法
typedef struct{
short m1;
char m2;
int m3;
} Foo;
printf("Offset of Foo::m2: %d Foo::m3: %d\n", &((Foo*)0)->m2, &((Foo*)0)->m3);
>>84 んなことしなくても規格にちゃんとマクロ offsetofがある。
offsetofが何をしているかということを考える意味では84のコードも役立たずではないが。
>>84 で大抵大丈夫だと思うけどoffsetofを使った方がいい。
空ポインタがアドレス0の位置を指すという保証はないからね。
>>79 それは一見、一理あるが・・・
int a, *p, **pp ;
と宣言した時に、メモリ上に確保されるのは、
a、*p、**pp
ではなく、
a、p、pp
なんだよね。
*pや**ppがint型と読むのなら、
*pや**ppのメモリが確保されるべきじゃない?
>>86 ちがう。
*(何か)NULL
ならば、NULLポインタが0番地という保証はないかもしれないが、
*(何か)0
ならば、0番地という保証があるでしょう。
というかNULL == 0って言語仕様で決まってたような・・・。
>>88 「空ポインタ」と「空ポインタ定数」の違い。わかるかな?
0をポインタに変換したときに、0番地に変換される保証はないの。
>>89 そうだっけ
近年は保証するように変わった記憶があったけど
>>90 0番地にアクセスできなくなるから、有り得ない。
>>92 でもおかしいよね
アドレス0にアクセスする方法が無いのが根拠だとしたら
特別なビットパターンであらわされるアドレスにアクセスする方法も無いよね
ああ、そういうことか。 「特別なビットパターンであらわされるアドレス」は、普通はもともと(仮想)メモリの外にある。 空ポインタにアドレス0を割り当ててる場合でも事情は同じ。
>>86 stddef.hに定義されているoffsetofマクロも
>>84 と
同じじゃん。
貴方の主張が正しいなら
#define offsetof(s,m) (size_t)&(((s *)0)->m) - (size_t)&((s *)0)
こんな感じにしなきゃいけないと思うが。
本来の意味からすれば相対的な位置を知りたいんだから
自分はこっちが正しい気がする。
まぁ、あれだ。 ポインタ使わずに済むなら、使わない方が良い、ってことだ。 バグのもとだし、後から見て分かり難いプログラムになるからな。 キチガイみたいにポインタのポインタのポインタのポインタとか 使って書かれてるプログラムを見せて、自慢げに講釈たれてる 自称スーパープログラマーが昔会社にいたなぁ・・・
( д ) ゚ ゚
やね○らおのことか
うん、ポインタは使わないほうがいい。再帰でなければmain関数以外なくなって良い。
>キチガイみたいにポインタのポインタのポインタのポインタとか >使って書かれてるプログラムを見せて、自慢げに講釈たれてる >自称スーパープログラマーが昔会社にいたなぁ・・・ 俺の最高記録は * 4つだが、 * 5つ以上を使った事のある奴 (もちろん意味のあるコードで) っている?
>>101 構造体も一種のポインタと考えて良いなら、5個まで
int*********i;
>>91 じゃぁどうやって0番地にアクセスするの。
そもそも、ポインタの値 = アドレスとは限らないよね。
メモリの特定のアドレスへのハンドルだと思ったほうがいいのかな。
ポインタのポインタって無意識のうちに使わない?
a->b->c->d->e
なんていうのも、そうなんだしさ。
105 :
デフォルトの名無しさん :2005/05/10(火) 12:36:17
>>104 > じゃぁどうやって0番地にアクセスするの。
Cから直接アクセスできればそれを使えばいいし、できなければアセンブラでも使えばいい。
アドレス指定でアクセスするという行為自体が環境に強く依存するんだから、
移植性は気にする必要はないだろう。
>>88 C のソース上、ポインタとして定数「0」が記述された場合、
それは NULL ポインタとして判断される。
NULL ポインタ値の実装値が、
All 0 のビットパターンであるかどうかは環境依存。
107 :
デフォルトの名無しさん :2005/05/10(火) 12:59:12
ポインタのポインタのポインタ・・・みたいなのは、とにかくtypedefして使うのが他の人に対する礼儀。 LispでもCでも、明示的なデータ構造なり型を定義せず書くのは、 デッサン画のようなもの
でもさ、typedefはなるべく使いたくないわけよ あれは型を隠蔽してしまうから、もちろんそのために使うんだけど たとえば time_t こう書かれちゃうと、一瞬「これって比較していいんだっけ?」と 躊躇してしまうよ。結局一度はtypedefの定義元を必ず参照する。 ポインタとは関係ない話だけど
>でもさ、typedefはなるべく使いたくないわけよ >あれは型を隠蔽してしまうから、もちろんそのために使うんだけど 型を隠蔽?はぁ?
typedefは 実装を抽象して、 抽象データ型に近づけるためのもの。 アセンブラで16進コード弄り倒す人間には、関係ないけどなw
113 :
デフォルトの名無しさん :2005/05/10(火) 13:43:11
>>111 typedefは、型を定義するもの。
データ構造の実装を抽象=隠蔽して、
宣言的なデータ構造に近づけるのが目的。
もちろん、16進ダンプおっかけるような仕事には無関係だけどなw
ほっとけ
117 :
デフォルトの名無しさん :2005/05/11(水) 00:06:54
>>115 おまえが本当に馬鹿なのはよくわかった。消滅しろ
118 :
デフォルトの名無しさん :2005/05/11(水) 00:10:25
あぁ、またやってる、やってるw ここに常駐してるバカは、 概念と単語の結びつきが特殊だからな。 "int *p"の"int *"が「型定義」と妄想しているのだろうな(ぷ
120 :
デフォルトの名無しさん :2005/05/11(水) 00:15:43
>>117-119 素人イジメ倒すの(・Λ・)イクナイ。
もっと、お母さんみたいに優しく教えなきゃ、かわいそうだよ
スマソ、首吊ってきます・・・
てst
125 :
デフォルトの名無しさん :2005/05/11(水) 00:26:44
http://127.0.0.1/ wwwwwwwwwwwwうぇwwwっっうぇっwwwwww
wwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwうはっwww
126 :
デフォルトの名無しさん :2005/05/11(水) 00:31:23
http://192.168.0.1/ wwwwwwwwwwwwうぇwwwっっうぇっwwwwww
wwwwwwwwwwwwwwwwwwwww
wwwwwwwwwwwwwwwwwwうはっwww
127 :
デフォルトの名無しさん :2005/05/11(水) 03:35:59
128 :
デフォルトの名無しさん :2005/05/11(水) 08:37:04
むしろで逝`
>>96 それはあなたの持っているコンパイラのstddef.hがそうなってるってだけでしょ?
規格でそう実装しろといってる訳じゃない。
空ポインタがアドレス0の環境なら
>>84 で十分。
違う環境なら違うように書くでしょ。
char mozi[] ="unkounkounko"; int sum; for(int i=0; i < 12; i++) { sum = sum + mozi[i]; } このようにすれば変数moziの1バイトごとの合計値は求めれると思うのですが 2バイトごとに求めるにはどうしたらいいでしょうか?教えてくださいお願いします。
131 :
130 :2005/05/11(水) 23:08:37
すいません聞く場所間違えました
おまえらに聞いた私がバカでした
>>132 >>130 のこと?
かわいそうなので解答。
for(int i=0; i < sizeof(mozi)/sizeof(short); i++) { sum = sum + ((short*)mozi)[i]; }
134 :
130 :2005/05/12(木) 10:45:42
>>133 すいません、4バイトの場合も教えてくれませんか?
135 :
130 :2005/05/12(木) 10:53:36
すいません解決しました
136 :
130 :2005/05/12(木) 13:07:39
いいえ解決しました
137 :
130 :2005/05/12(木) 13:10:01
こんな板で聞いた俺がバカでした。
138 :
デフォルトの名無しさん :2005/06/10(金) 11:01:27
まとめ 一、型修飾子と間接参照演算子がカブっている。 宣言系と演算系の性質の全く違う記号がカブっている上に 型修飾子を型につけても変数名につけてもいいという 無意味な自由度のせいで 余計に見にくくなっている。 二、積の算術演算子とカブッている。 性質がまるで違っていて 他に使える記号があるのになんでわざわざ 算術演算子とカブらせるのか。無意味に見にくい。
文句をいうだけなら誰でもできる
140 :
デフォルトの名無しさん :2005/06/11(土) 03:45:02
開発者が何でも"*"を使いたくて仕方がなかったんだろう。 そこでオーバーロードですよ。
* はアセンブラ由来じゃなかったっけ? もともと参照の意味で使ってたとか
スマソ 上で既出だった…
p(hoge)
無理に記号じゃなくてモナー point( )とか refer( )とかでよかったんでは。
point()とかrefer()とか、それじゃ関数じゃねぇか
ついでに add() とか sub() とか call_function() とかもよろしくな。
マンドクセ
148 :
デフォルトの名無しさん :2005/06/12(日) 13:06:46
型付きポインタ型変数と、非ポインタ型変数の 記述上の区別がないのは煩雑だと思わないか? int型ポインタ型の変数と、ただのint型変数を 記述上で全く区別しなくていいわけだ。 どっちも "a" だとか "b" っていう名前だけで定義できてしまう。 記述を見ただけじゃ型付きポインタ型変数か普通の変数だかもわからないし 指し型もわからない。 $でも何でもいいから せめてポインタ型かそうでないかの区別くらいあったほうがいいんじゃなかろか
ポインタ変数の宣言方法を変えればいい。 pointer<int> pi;
悪くないけど、頻繁に使われる分字数が気になるな… ここは例外として *<int> ptr; でOKとか。*は型名って事で。 ptr->deref, ptr = var->ref ...
ミスっち。アロウ演算子じゃなくて.だった。
152 :
提案 :2005/06/12(日) 14:43:18
[宣言] // ※ ポインタ型変数は、変数名の先頭に // "p" または "p_" を付けなければ宣言エラーとする(宣言させない) ptr<int> p_int_Count; // OK ptr<int> p_Count // OK ptr<int> pCount // OK ptr<int> Count; // Error!! invalid PointerVarName [間接参照] "*" は算術記号とカブるので使わない。 "指す"(at)という意味で "@" を使う @(p_i_Count) @pCount
153 :
デフォルトの名無しさん :2005/06/12(日) 14:49:26
算術記号としての * を廃止します。 今後、掛け算には新たに x を使用します。 変数名としての1文字単独の x は禁止します。
154 :
デフォルトの名無しさん :2005/06/12(日) 14:52:36
>>153 文字だと単項演算子と、くっつけて書く場合に問題が出る。
Count*=3;
を
Countx=3; にしたら意味が変わってしまうし
記号だと iA*iA といったくっつけた書き方ができるが
文字のxだと
iAxiA で違う名前になってしまう。
二分探索木にNODEを挿入する。 NODE *insert(KEY key) { NODE **p, *new; p = &root; while(*p) { if(key == (*p)->data) return NULL; else if(key < (*p)->data) p=&(*p)->left; else p=&(*p)->right; } if( (new=(NODE *)malloc(sizeof(NODE))) != NULL ) new->data = key; new->left = new->right = NULL; return *p=new; } ↑本に載ってた
こうするのとなにがちがうんですか? NODE *insert(KEY key) { NODE *p, *new; p = root; while(p) { if(key == (p)->data) return NULL; else if(key < (p)->data) p=(p)->left; else p=(p)->right; } if( (new=(NODE *)malloc(sizeof(NODE))) != NULL ) new->data = key; new->left = new->right = NULL; return p=new; } if文のかっこがぬけてるかも。
この方がわかりやすいな // p<Type> : ポインタ型変数宣言 // @ :(at) 間接参照 p<NODE> insert(KEY key) { p<p<NODE>> ppR, p<NODE> pNew; ppR = &root; while(@ppR) { if(key == (@ppR)->data) return NULL; else if(key < (@ppR)->data) ppR=&(@ppR)->left; else ppR=&(@ppR)->right; } if( (pNew=(p<NODE>)malloc(sizeof(NODE))) != NULL ) pNew->data = key; pNew->left = pNew->right = NULL; return @ppR=pNew; }
158 :
デフォルトの名無しさん :2005/06/12(日) 15:18:27
>>158 既存のコードも全部そうするのかよ。
そんなクソ文法を考えるセンスが素晴らしいな。
Javaみたいにコンパイルオプションつけとけばいい
演算子はくっ付けて書きたい俺様が来ましたよ
接頭辞にpをつけなきゃエラーにするってのはすぐにできそうだな。
163 :
デフォルトの名無しさん :2005/06/13(月) 01:38:27
>>161 演算子をなんでもくっつけられると思ってんじゃねーぞ
ポインタ同士の割り算は離して書くだろうが
括弧をつけるとか言い訳すんじゃねーぞ
ホントお前は知恵足りんだな
なんだこの馬鹿は
>>164 悔しかったら煽りじゃなくて反論をしてみせろ
第三者から言わせてもらうと 悔しがってるのはお前だろw ちょっと批判されたくらいで熱くなり過ぎ。 お前がいいと思うんなら勝手にそう思ってりゃいいよ。
>>162 ハンガリアンのごとく嫌われそうな希ガス
つーか、pで始まる識別子を使いにくくなるという時点で却下。
>>163 まず
>ポインタ同士の割り算は
「頭悪いなー」と気付かないと。
ポインタにpをつけるのを義務にしちゃうと ポインタのポインタはppに ポインタのポインタのポインタはpppに となっちゃうんですかねやっぱり
int****ppppX; イヤニナルナ・・・
しかしそこまで*が並ぶこともないだろう。
175 :
デフォルトの名無しさん :2005/06/13(月) 20:01:02
〜型のポインタのポインタのポインタのポインタの… などという ひとりよがりの型を作るやつは スパゲッティと同じで嫌われそう
>>175 ポインタのポインタのポインタぐらいまでは普通に必要。
>>146 >call_function()
()演算子を廃止して、関数を呼び出す関数を作るとすると
関数を呼び出す関数をで呼び出すわけだから、それを呼び出す演算子はcall_functionで…
call_function call_function call_function call_function call_function call_function...
こんなかんじか?
お前ら意味が無いこと考えるのがホント好きだな
意味あるよ〜。 ポインタの糞なところを指摘し 改良しようという立派な意味が。
int a; ptr<int> p; //int型ポインタの宣言 p = ptr_of(a); // ptr_of演算子
>>180 ポインタの糞と思うとこを指摘して、誰かがが改良するのを待つという意味だろ
それとも、オマエが改良できるのか?(´,_ゝ`)
>>182 意味わからんな。
改良なんて誰がしたっていいだろ。
こうしてみんなで意見を出し合えば、
やってくれる香具師も出てくるってもんだ。
グダグダ言ってないで君も何か案を出しなさいよ。
もしかしたら開発言語界の寵児になれるかも知れんよ。
うはwwwwwwww他力本願全開wwwwwwww
2ちゃんで他力本願とか指摘されてもなw
Javaみたいに、本当はポインタなんだけど
ポインタであるということを意識させないのは
すごい画期的なアイデアだと思うんだが
>>183 はきっと気づいていないんだろうな
その件に関して、Java に新規性はない C 以前から参照渡しの言語はあったが、C はそれを選択しなかっただけ アイデアを出した所で、実装が出来る人間はそんな事には確実に興味が無い 何で今更互換性を無視してまで C を改良しなくちゃいけないのか…
>>187 これだけ多くの人がつまづき、バグの元になっている現状を見なさい。
ポインタという欠点を放置しておくことはC言語業界の損失だよ。
解決できれば、互換性を捨ててでも乗り換える価値がある。
>>188 C++でもポインタを生のまま使いたがる人の存在はどう説明する?
>>189 それは単に保守的なだけと思うが。
無理にC++を使わされてるCプログラマと思う。
彼らは被害者なのだから、いたわりなさい。
>>186 ポインタであることを意識しないと非常に不安なんだが…。
つーか、意識しない人間がCのポインタで色々やらかしてる気がする。
意識したくないなら、他言語に移ればいいだけだと思うよ。
192 :
デフォルトの名無しさん :2005/06/19(日) 21:44:31
昔は「配列よりポインタで記述した方が早いコードを出力する」という 信仰があったが、今は高性能なコンパイラの最適化により、 同じ処理をポインタ使うもの/使わないもの、2つ書いても 両方ともほとんど同じアセンブラコード出力すっどえ。 これは実験してみれば簡単に目で確かめることができる。 C#の選択は正しいど。
>>191 CわかってるやつにJavaを教えるときは
「あれ全部ポインタだから」と言うようにしてる。
何の言語でアレ、わかってないやつは
なにをやってもだめだし、すぐ理解するやつは
なにやってもそつなくこなす。だからどうでもいい
>>188 で、int *p を ptr <int> p と書けば、多くの人は躓かなくなるのか?
なんで * ばっかり使ったのかなぁ。
$と#を使えばよかったのに
int# pA = pB ;
$pA = 10 ;
とかにすれば・・・。
>>189 C++でポインタを生のまま使わない方法ってどんなの?
>>188 ポインタなんて嵩が知れてると思うが…
自分のレベルでしか物事を判断出来ないようね。
個人で把握できる程度の小さいプログラムしか書いたことのない人がそういうことをよく言う
>>197 デバッグとかテストとか、禁じられてる国から来た人ですか?
>>195 参照を使ったり、vectorなどのコンテナを使ったりってことだろ。
>>196 君こそ自分の視野だけで物事を計ってるだろ。
君は書店に糞ほどポインタの解説本・攻略本が
並んでる現状をどう見る?
難解だからという以外の評価があるかね。
ポインタはCの恥部でありガンなんだよ。
>>200 ポインタがなければ C は価値を失う。
理解出来ないなら、そうまで必死に C を使おうなどとしなければ
幸せになれるのに。
>>199 サンクス
参照やSTLはポインタよりも使うのが難しいと思う。
>>198 規模が大きくなればなるほど、
デバッグやテストでバグをゼロにすることはできません。
>>200 それって入り口でつまずいた人の為に用意されている物でしょ。
自分で解決の糸口を見つけられない人の補助教材。
入り口を抜けられた後にも当然 C の問題はある訳でしょう。
メモリマネージメントとか、他の言語ではカバーされていても
C では環境依存になる様な処理とか。そういうのを含めると、
ポインタの記法は些末な事と言っても良いと思うんだよね。
スレタイにある様に、C のポインタの記法はクセがあると思う
けど、今から仕様を変更するだけの労力に見合う物じゃないと
思う訳。STL が難しい人に、皆に受け入れられる提案が出来る
とは思えないよ。
>>202 >参照やSTLはポインタよりも使うのが難しいと思う。
Javaについてはどう思う? 一般的にはCより難しくないと言われているが。
#あれは私にとってはポインタを生で触れなくて使い難く感じるのだが。
> 一般的にはCより難しくないと言われているが。 あれはガベコレあってのことだからなあ。
207 :
202 :2005/06/20(月) 16:15:39
>>204 まさか。
でも規模が小さければバグがゼロということもありうるよ。
たとえば
int add(int a, int b) {
return a+b ;
}
とかになると、仕様の書き方しだいでバグがゼロになってしまう。
って、そんな非現実的な話はどーでもいいっすね。
>>205 Javaは常に参照なので難しくないと思います。
使い方を間違えにくいですから。
C++は参照とそうではないものが混在して、
使い方を間違うと混乱のもとになるので難しいです。
char** ppsz; const char** ppsz; char const** ppsz; char * const* ppsz; char const* const* ppsz; char const** const ppsz; char * const* const ppsz; char const* const* const ppsz;
char ** const ppsz; がねぇぞ!w 先頭constは仲間外れな気はするな。
tmp.c:2: error: conflicting types for `const char**ppsz' tmp.c:1: error: previous declaration as `char**ppsz' tmp.c:3: error: redefinition of `const char**ppsz' tmp.c:2: error: `const char**ppsz' previously declared here tmp.c:4: error: conflicting types for `char* const*ppsz' tmp.c:3: error: previous declaration as `const char**ppsz' tmp.c:5: error: conflicting types for `const char* const*ppsz' tmp.c:4: error: previous declaration as `char* const*ppsz' tmp.c:6: error: conflicting types for `const char** const ppsz' tmp.c:5: error: previous declaration as `const char* const*ppsz' tmp.c:7: error: conflicting types for `char* const* const ppsz' tmp.c:6: error: previous declaration as `const char** const ppsz' tmp.c:8: error: conflicting types for `const char* const* const ppsz' tmp.c:7: error: previous declaration as `char* const* const ppsz'
エラーが出ることなど一目でわかるだろ。 ホレ void main( void ) { const char** ppsz = ( const char** )0; char** ppsz0 = ( char** )0; char const** ppsz1 = ( char const** )0; char * const* ppsz2 = ( char * const* ) 0; char const* const* ppsz3 = ( char const* const* )0; char ** const ppsz4 = ( char ** const )0; char const** const ppsz5 = ( char const** const )0; char * const* const ppsz6 = ( char * const* const )0; char const* const* const ppsz7 = ( char const* const* const )0; ( void )ppsz; ( void )ppsz0; ( void )ppsz1; ( void )ppsz2; ( void )ppsz3; ( void )ppsz4; ( void )ppsz5; ( void )ppsz6; ( void )ppsz7; }
× char const** const ppsz5 = ( char const** const )0; char * const* const ppsz6 = ( char * const* const )0; char const* const* const ppsz7 = ( char const* const* const )0; ○ char const** const ppsz5 = ( char const** )0; char * const* const ppsz6 = ( char * const* )0; char const* const* const ppsz7 = ( char const* const* )0;
ppsz4 もだった orz
*でめがちかちかするですつ
匂いでですか?!
ウホッ
どなたか、C/C++のポインタとC++の参照について、JAVAの参照と関連付けて教えてください。 むずかしいです。
>>217 難しいと思うのは邪念がある所為。
心眼を持ってすれば同じものであることが判る筈。
>>218 なんだか徐々にわかってきました。
でもまだ難しいです。
自分の周りに円を描き、そこから出ないようにするのがCのポインタ フラフープを手に持って走り回るのがJavaの参照
こんがらがりますた
>>220 JAVAはヤリたい放題だけどCは窮屈ってことでしょうか?
すみません。ヤリがカタカナになってますが深い意味はないです。
220はその気になれば簡単に円の外へ出れるけど、フラフープからは脱出できない(しづらい)と言いたいのだろう。
Cが相撲レスラーで JAVAが子供ってことじゃないの?
Cのポインタの必要性って何ですか? C++だとポインタより参照の方が早くて、constをつけるともっと早いと聞きました。 JAVAの参照も早いですか?
俺はポインタが好きだ。だから必要だ。
>>226 「早い」かどうかは知らんが、const参照はより「速く」なる可能性がある。
参照はNULLができんし
ポインタ = 参照 + イタレータ + NULL; Cではどれにも使える魔法のような存在。 C++では参照がほしいなら参照を、イタレータがほしければイタレータを使えばいいし、NULLかもしれないというのはboost::optionalがある。 イタレータを使うとは言ってもstd::vectorやboost::arrayでは結局ポインタ型に帰着するだろうけどそこは気にしない。
>>226 Cからポインタとったら何も残らない希ガス・・・
C++のポインタと参照ならびにconst修飾子をつけた
場合の差異については、コンパイラにアセンブラ
ソースを吐かせて比べてみてはどう?
const参照が早いというのはどうせクラス・構造体の値渡しより早いということだろ。 それなら別にconstのありなし・参照かポインタかということは無関係。 その中でもconst参照だけが値渡しとまったく同じように使えるというだけの話。
山椒の場合アドレスのコピーすら作られないって話じゃなくて?
メモリへのライトアクセスが発生しないという前提のコードを 吐いてよいというのもあるかと。
Cのconstについて、いまいち理解できない void hoge( const char *hoge ) と書いたときは hogeを変更しないよ という宣言? それとも *hogeを変更しないよ という宣言? void hoge( char const *hoge ) と書いたときは *hogeは保護されるとして、hoge[1]以降は?
>>235 http://kmaebashi.com/programmer/pointer.html#const const char *hogeはhogeの指す先(*hoge)を変更しないという意味。char const* hogeと同じ。
hoge自体を変更しないというのはchar *const hogeになる。
hoge[1]は*(hoge + 1)と書くのと同じ意味。
+演算子はどちらかにポインタ型の場合、結果は元と同じポインタ型になる。
つまりhoge + 1もconst char *型になるので、それを*で参照剥がしした先は変更できないのでhoge[1]も変更できない。
>>236 ありがとう
お礼に グーグルで「ポインタ」で検索してみて
イメージ検索で
犬がひっかかりますた!
本則では先頭const禁止ってなことになれば少しは混乱が減ると思ふ。 当然、互換性の観点から、デフォルトでは先頭constは警告なし。 が、イィと思うんだけどなぁ・・・
一つのことをやるのにいろんな記述方法があることがポインタの問題点だ。 そんなんでは人によりコード記述の流儀が違いすぎて バグの元だし保守しづらくなる。 やはりCOBOLのように、誰が書いても同じコードになることが 業務系開発言語には最重要に思う。 てか、システム記述言語であるCを業務系に使うことが誤りなんだよな。
業務なら決めておけばいいだけ
>人によりコード記述の流儀が違いすぎて >バグの元 流儀の違いがバグの元になるわけね〜。 解釈する能力が足りないからだろ。
>>242 >やはりCOBOLのように、誰が書いても同じコードになることが
ほほぉ?
誰が書いても同じコードになるプログラムなんかねーよ・・・
Cのポインタだけでなく、自由度が高いと複数人でコードを書いたときに わけがわからんことになりやすいって話だろ。 コーディング規約レベルでは守らないやつも出てくるし 言語である程度自由度を下げておくというアプローチもありでしょ。
>>247 それは判るが、COBOLを引き合いに出した>242は問題の本質を判っていない気がする。
249 :
デフォルトの名無しさん :2005/07/09(土) 23:40:43
人の流儀にはしたがわねーって流儀の奴が多い業界だからね。 あ、その業界でもそうかな?
251 :
デフォルトの名無しさん :2005/07/10(日) 00:40:06
>>1 通常の変数のポインタは不自然じゃない。
それよか、関数ポインタの方が不自然。
int (*pproc)(void); // 関数ポインタ定義
int proc(void); // 関数プロトタイプ
pproc = proc; // ポインタコピーして
pproc(); // ポインタから実行
宣言としては、 (*pproc)() と proc() はint型を示すものとして理解できる。
ならば、 *pproc と proc はintを返す関数として理解できる。
なら、
pproc = &proc; // ポインタコピーして
(*pproc)(); // ポインタから実行
の方が自然じゃないのか???
>>251 昔は後者のようにしないと駄目だったようだが、
自然だということ以外メリットがないということで、
前者のルールになった。
ちなみにこんなこともできる。
(*******************printf)("hoge");
255 :
デフォルトの名無しさん :2005/07/10(日) 15:36:34
ポインタ参照を@とか使われていない記号にして、かつ後置にすれば問題が無かった予感。
ついでにアドレス参照演算は@前置とかにすれば統一感がとれて矛盾も生じないと思うが。
int p@; // ポインタ宣言
@int p1, p2; // これでもポインタ宣言としてOK
int n; // 普通の変数
p = @n; // ポインタコピー
p@ = 10; // ポインタ参照で変数を変更
アロー演算子なんて取ってつけたようなふざけた演算子も要らなくなるし。
不必要な括弧の連発もしなくてすむし。
int pproc@(void); // intを返す関数ポインタ宣言
[email protected] = 20; // アロー演算子不要
Pascalがそうか。
256 :
デフォルトの名無しさん :2005/07/11(月) 21:18:26
てか間接参照は[0]でいいじゃん。 C++の純粋仮想関数だって=0みたいな気色悪いことやってるんだし。
257 :
デフォルトの名無しさん :2005/07/11(月) 22:16:38
>>256 >C++の純粋仮想関数だって=0みたいな気色悪いことやってるんだし。
確かにあれはテラキモス。
D&Eにはキーワードを導入しようとしても反発が強くてできそうになかったと書いてある。
>>1 ポインタというものを変数の裏の顔というより、
ポインタ型という型として認めてやってからは矛盾を感じなくなった。
D言語ならint* foo,bar;でどっちもポインタ型にできるみたいで能動的。
C++は「型*」でポインタ型という一つの型として扱いたがってたはずだが、 int* foo,bar;としてもポインタになるのはfooだけなんだよなぁ
C言語を切り捨てれば、C++も、もっと良くなるのにね! ・・・あっ、そうしたのがJavaか・・・
しかしJavaはすべての面においてC++より良くなったとは思えない。
ところで、今更なんだけど、
>>18 だとなんでCが極自然だって
ことになるんだ?
Cは高級アセンブラだから
そうじゃなくて、
>>1 の書き方よりもC言語のポインタの書き方の方が
自然だとする根拠を、なぜ
>>18 で説明出来るのか?
ということなのだが。
266 :
デフォルトの名無しさん :2005/07/12(火) 18:15:53
そんな昔のこと言われてもなあ あははははははははは
>>265 リファレンスとでリファレンスがちゃんとマップされてるから
>>265 リニア(配列の類)なデータを渡されてそれをアセンブリで操作することをやったことがある?
無ければ直感的にはわからないかも。
言語仕様でそう決めたんだから
>>1 が幾ら文句言っても何も変わらない。
以上
以下、このスレは新言語原案募集スレになりました。(w
C言語のポインタ部分だけを改変した自慰言語の開発に取り掛かろうと思います。
>>269 なんでそう決めたのかの経緯を知ることも重要だろ
どうせK&Rやコンパイラ製作者のエゴだろ
Cの謎仕様はいくつもあるけど
>>1 のはおかしいとは思わないし
代案の方がよっぽど変。
自慰→H
277 :
デフォルトの名無しさん :2005/07/14(木) 14:52:45
現在、goto文の使用を禁じるコーディング規約が一般的であるように、近い将来、ポインタの使用を禁ずるコーディング規約が一般的になると思われるが どうよ。例えば次のように↓↓ << xxx社yyy部コーディング規約 >> ●規約第x.y.z章: goto文の使用禁止 その当時としては、goto文がCPUの動作を制御するもっともプリミティブな命令で かつスマートで分かりやすい記述であった。 その後、プログラミング言語の発達によって、より抽象度の高い記述方法で、goto文を使わなくてもCPU動作の制御をできるようになったため、 goto文の必然性は小さくなった。 (もちろん、その抽象度の高い記述をコンパイルした結果(=機械語レベル)では、 それらの処理は、goto文(=jump命令) によって実現されている。 なぜなら、jump系命令は、CPUの動作にプリミティブなもので、 これなしでCPUを制御しようとすると、非常に回りくどい方法となってしまうためだ。 つまり、goto文(=jump系命令)は、見かけ上は消えていても、その裏では必ず使われている。) 最近では、 1.可読性を損ないやすい、 2.バグの温床となりやすい 3.高級言語ではgoto文を使わない方が制御をスマートに記述できる との理由のため、goto文の使用を禁止しているコーディング規約が多い。 ●規約第a.b.c章: ポインタの使用禁止 C言語全盛時、ポインタがデータ構造を制御するもっともプリミティブでかつスマートで分かりやすい記述であった。 その後、プログラミング言語の発達によって、より抽象度の高い記述方法で、ポインタを使わなくてもデータ操作を効率よくできるようになったため、ポインタの必然性は小さくなった。 最近では、 1.可読性を損ないやすい、 2.バグの温床となりやすい 3.高級言語ではポインタを使わない方がデータ操作をスマートに記述できる との理由のため、ポインタの使用を禁止しているコーディング規約が多い。
278 :
デフォルトの名無しさん :2005/07/14(木) 14:57:12
おれの予想では、5年後には、ポインタの使用は禁じ手になると思うな。 >277 ようなコーディング規約が各社で運営されて "それでもポインタ使う派"と、"新しい記述を推進する派"で、2chで終わりのない論争を 続けているだろう、と予想した。 さあ、だれか、 >277 を否定してみてよ! さあ!さあ!!さあ!!!
オレがその会社のプログラマなら、そのコーディング規約に従う。 goto文やポインタを使わなくても きれいなコードはそれなりに書ける。 この程度の下駄なんてたいした問題じゃない。 本当にひどいコーディング規約になると 構造体はいつでも必ず実体で扱うこと とか C++なら継承禁止 とか枚挙にいとまがない
それよりも、未だに一行80バイト、コメントは41カラムから、変数名は20文字以内、 などの戯けたコーディング規約に早く消え去って欲しいと思う恭子の頃。
おまえら、Java使いだろ?
>>277 std::vector<T>::iteratorは?
ポインタがだめなら std::string str = "abc"; もダメなんだよな?
>>280 いや、それはなるべく守ろうよ
コメントはどうでもいいとして
>>283 そんなもんでポインタポインタ騒ぐヤツ居ないと思うが・・・
>>277 以降のはコピペだね。
どっかで見たよ。
一行80バイトは馬鹿馬鹿しいね。
行を折り返すことで発生するトラブルもあるんだしさ。
>>286 でも、80バイト以内に収まるよう「心がける」ことは
決して悪いことではないと思う。
多少はみ出たって気にはしないけど
やり過ぎは良くないが、こだわり過ぎて雁字搦めになるのも良い物ではないってことか
規約というのは常に最下位レベルに合わせて作成される
タブストップが8でない場合、インデントはスペース使ってくれ。 何も入っていない人様のWindowsでEUCの入ったソースを見ようと 思ってIEに食わせたら眩暈がした。
291 :
280 :2005/07/14(木) 23:14:40
>>287 甘いな、1行80バイト以内じゃない、1行80バイトなんだ。
甘いとか甘く無いかとかいう問題か?(爆笑)
293 :
280 :2005/07/14(木) 23:31:18
>>292 そのプロジェクトに参加して初めに組んだプログラムは、ソース整形ツールだった。
一行が長くなる原因・・・
10個近くの引数を取る関数・・・それ自体がそもそも間違った存在なのではあるけれど、
そういうのがある以上、一行80バイトを越えてしまうのは仕方ない。
一行一引数での書き方もあるが、それはケースバイケースで使い分けるべきで、
なんでもかんでも、どちらか片方の書き方に統一しろというのはナンセンス。
中カッコのネストが深くて行頭にタブが10個以上入っている・・・
それは関数が大きいからなのだが、時には大きいほうが良い場合もあるからなぁ。
>>290 インデントにスペースを使うのは勘弁してくれ。
もっと最悪なのは、インデントにタブとスペースを混ぜて使ってることだが。
タブにしておけば、見る人が好きな文字数にして見ることができるじゃないか。
スペースを入れた瞬間に、そのソースのタブのサイズは固定になり死ぬ。
>>294 好き好んで混ぜるというよりIDEのエディタがタコで混ざるパターンが多いかも
改行したときの自動インデントとタブ入力の扱いが違ってたりとか
>294 そういったビューアでもツールでも標準でついていれば文句は言わん。 IEにタブ ストップの文字数設定する項目あるか? 劣悪な環境下でもなるべく可読性をそこねないコードを吐けって話だ。 タブ ストップ 文字数を自由に変えれる環境にentab、detab追加する くらい簡単だろ?
そもそも何でIEで見ようとするの? IEにそういう項目がないからって噛み付く意味がわからない。
(´Д⊂ウワーン だから劣悪な環境だと・・・
インデントはタブであって欲しい人がいるようだが、Delphiなんかは デフォルトのインデントは2だがタブ ストップは8文字だったかと。 んでIDEが吐いたテキストを便利なエヂタで開いてタブ文字数 変えると・・・
>>295 そのIDEは余りにゴミだな。
劣化unix使いで、viを動かしている端末エミュレータ間でコピペする阿呆がいる。
その場合、XWindow上だと空白でコピペされるんだよね。
よって、インデントがタブか空白かでオリジナルかどうか判る罠。
>>297 EUC→MS-Kanji変換を何もしなくてもやってくれるからだよ。
何もしなくても変換してくれるとして何でIEでなければならないのか不明。
危険な無料ウェアを勝手にインストールする事が禁じられているから
セットアップ終わったばかりのWindowsでソースを見る必要が生じることもあるでしょ。 実際客先であったんだけど。
306 :
マリー :2005/07/15(金) 02:08:40
危険な無料ウェアがダメなら市販ソフトを買えばいいじゃない。
市販でも、怪しげな怪社の祖父とは禁止されているかと。 ソース次とか・・・
思ったが
>>304 は上の馬鹿さ加減に嫌気がさしている・・・んでは?
M$だって補償してくれる訳ではないんだけどねぇ。
そんなくだらないことのために、 ソースの保守性を下げるのかよ。 馬鹿じゃないの? っていうか、なんでWindows環境なのにEUCなんだよ。 そのソースをWindows環境に持ってくる前にEUCから変換しろよ。
そうだね UNICODEにすべき
構築、稼働はLinuxだけどクライアントへの説明などはWinってぇのは普通かと。 nkfとか入ってないのは前レスを。
いや違うな・・・ ソースはタブで書いて、 表示用にタブ→スペースに変換してから、Windows環境に持っていけばいい。
をっ!EUCって何だか分かったな! 勉強になっただろ。
貫通力の問題なんだが・・・ 果てはCP/M(って何?)から今の全てのプラットフォームでおk
つか、タブ・スペースごときで保守性とか言ってんなよ...
つーか、おまいら、ポインタの話にもどせ。1行の文字数は別スレでやれって。 >277の反論はないのか? >282 >283の言う、std::string などは ポインタ排除の方向に C言語がかわりつつあることの象徴だろ。
ファームウェア書いたことある人いますか?
どうでもいいけど引数の参照が void hoge(int &ref) { } void hogehoge(void) { int a; hoge(&a); } みたいにならんかったのは何故? いつだったか参照に気付かずにバグりそうになった事が…
>>318 あなたはこう書きたいですか?
std::string str = "HogeHoge";
&cout << &str;
320 :
283 :2005/07/15(金) 07:46:12
>>316 C/C++ではポインタを捨てることが出来ないと言いたいんだが…。
ポインタを使いたくなかったら他の言語に移ってください。
それで丸く収まります。
あなたの仕事がなくなろうがしったこっちゃありません。
つまり、文字列型がない以上、const char *を受けるコンストラクタが必要になるということですな。
それ以前にC++の参照は仕様が腐ってるから ポインタ排除は無理だな。 仮にstringだか文字列型を言語仕様でサポートしたとしても。
>>316 > >282 >283の言う、std::string などは ポインタ排除の方向に
> C言語がかわりつつあることの象徴だろ。
いつのまに,C言語にstd::stringが追加されたんだ?
触ってやるなよ
>>316 反論はあるけど、規約に反論しても仕事は進まんし。
規約はそれを作った人間/組織の技術レベルを反映するから読むと面白い。
それだけだよ
>>316 gotoはエラー処理以外は使用禁止なら無問題
あんまり使わんけどな。
ポインタ禁止って、、、2つ以上の値を返したい関数はどうやって作ればいいのだ?
もちろんCだから参照はないよな?
つ グローバル変数
いや、ネタはいいから
つ 構造体
それじゃまるで、ポインタを隠すことに終始したために見通しの悪くなったJavaの劣化版じゃないか。
C言語でポインタを使いまくり 見かけ上ポインタを考慮しなくてよいものをC++で作る なんか最近のトレンドっぽいね
うちの会社は組み込み系でリアルタイム性バリバリ必要なんで、 C言語でないとパフォーマンスでなかったんだが、 さすがに生産性を考えてC++に移行しつつある。 いまどきは、CPUもコンパイラも賢いから 組み込み系でも抽象度の高いほうへシフトしていっている。
ちなみにD&EにはC++の目標の1つとしてCと同じ速さで動くというのも挙げられている。
334 :
デフォルトの名無しさん :2005/07/16(土) 11:29:34
>>326 >gotoはエラー処理以外は使用禁止なら無問題
多重ループ脱出用途は駄目ですか?
まだやってたのか
try-catchもbreakもcontinuもgotoじゃん 近代言語でこういうのはgotoで実装してそうだなってのは 基本的に全部OKなんじゃね? whileあるのにgoto使うバカはほっとけばいいし
ループの中のswitch-case文の中からループ脱出したいときどうしてる?
gotoとポインタに関連ないからスレ違いだと思うよ
339 :
デフォルトの名無しさん :2005/07/16(土) 13:30:35
while(hoge){ try{ throw "ループから出させよやゴルァ!!!"; } catch(char *e){ if(strcmp(e,"ループから出させよやゴルァ!!!")==0) break; } }
C言語でないの?
スレタイを読めない人がいるとは思いたくないが
わかったようするに
>>1 は頭悪いんだ
すげー理解力
Cもポインタやめてリファレンスにしようぜ
344 :
デフォルトの名無しさん :2005/07/16(土) 14:58:09
議論の結果はどっかにまとめてうpしとけよ
c言語のポインタの文法は確かにおかしい。直感に反する記法を強いられる場合がある。 c言語の教師になる人や、コンパイラを作成しようとする人は、この事を意識する 必要がある。しかし、このことに気づかないままCをマスターする人もいるだろう。 普通にプログラムをする人には、文法のおかしさに気付かずに済めば、寧ろその方が 幸せかも知れない。 ただc言語のエキスパートが多数存在し、有益なコードが大量に作成されている事実 がある以上、もし「文法がおかしいから国際語には向かない。」といった発言があれば、 それはは間違いだし、謝罪し訂正するべきだと思う。
>>306 コンピュータ言語と違って自然言語は、
使っていくうちに変化するという特徴があるので
文法のおかしさが減ったものほど広く使われるようになる。
また広く使われるほど文法のおかしさが減っていく。
まぁ確かに、1から100まで規則性が認められない言語もあれば、 日本語のようにかなり規則性に富んだ言語まである。 フランス語が偶々前者に近いからといって、フランス語全てが 文法がおかしいというようなニュアンスの発言はお郷が知れるというものである。
フランス語は数字もまともに数えられない欠陥言語
お偉い人はつくづく要らんことばかり言いますな
数学を勉強する者にとっては、第二外国語は ドイツ語よりフランス語だよな。 フランスは数学の本場だし。
352 :
デフォルトの名無しさん :2005/07/16(土) 18:10:30
多重ループ脱出もそうだけど、 1回しか回らないループ(つまりループじゃない)を作って エラー処理時にbreakするってのは 邪道なの?正道なの?
do { : if (…) break; : } while (0); ってこと?別にいいんじゃね? でも一般に関数化してreturnの方がよさそう。
354 :
デフォルトの名無しさん :2005/07/16(土) 18:19:17
>>353 ふっふっふ・・・
関数作成数に上限があるコーディング規約なのだお
別にいいんじゃね? 変な規約。
オーバーヘッド対策か知らんけど、裏目に出るだろうな
素直にgoto使えばいいのに
359 :
デフォルトの名無しさん :2005/07/16(土) 20:57:44
>>352 それをやったプログラムで・・・
for(...){ //意味のあるループ
do{ // try代用のループ
if(...) break; // 意味のあるループを抜けるつもりで書いた
}
}
というミスをして1時間くらい悩んだ経験あり。
よって駄目・・・と言いたいが・・・
しかし関数化すると処理が見通しにくくなるし・・・
やっぱ特定のループを指定できるbreakとcontinue、あと例外処理は是非備えてほしい機能だな。
トランプを文字列みたいにカードクラスのポインタで表してるんだけど 最初カードを作るときに for (i = 0; i < 52; i++) { (card + i)->SetCard(mark, num); } ってやるとアドレスが全然進まないんだけど これじゃだめなの?
とりあえずカードクラス(クラス?)の定義と cardの定義、見せてみ。
ここまできたら何だっていいよ。 C系で言語仕様に関して詰まってることどんとこいだ。
// card.h class CCard { int mark; int num; public: CCard(); int SetCard(int mark, int num); int GetMark(); int GetNum(); }; // card.cpp CCard::CCard() { mark = 0; num = 0; } int CCard::SetCard(int mark, int num) { this->mark = mark; this->num = num; return TRUE; } // main.h CCard *card; card = new CCard[52]; こんな感じ
card[i].SetCard(mark, num);じゃないのかい? ポインタ配列をnewしてるんじゃなくて インスタンス配列をnewしてるように見える。 ごめん、ホントはブランク長くてよく分からない。
>>360 アドレスは進むだろ。
markとnumそのままだと、52枚とも同じカードになるんじゃないか?
やったぜ俺!
>>364 その通りだった
カードを配ったときにプレイヤーのカード総数を増やすのを忘れてた
>>365 進んでなかったアドレスをよく見たら先頭アドレスだった
CCard *card; card = new CCard[52]; このコードって危なくないかい? 51個のインスタンスポインタがCに管理してもらってないじゃん。
>>367 C/C++はポインタの管理なんかしないでしょ
delete[] card;
ってやれば52個とも解放できるので無問題
delete card; だとメモリリークするけどね
>>363 ヘッダで領域確保しちゃってるけどいいの?
せめて
// main.h
extern CCard* card;
・・・
// main.cpp
#include "main.h"
card = new CCard[52];
// 以下CCardの初期化コード(
>>364 の)が52個ほど(使う前であればいつでもいいけど)
・・・
にしてあげて。
>>368 for (int i = 0 ; i < 52 ; ++i)
delete card[i];
のようにしてる漏れは逝ってよしですか?
370 :
369 :2005/07/17(日) 01:32:18
ああ、delete card; が最後に来ます。
もう一つ上のクラスを作ってそこのデストラクタで 解放するようにした方がいいと思うぞ。
>>353 関数の途中からのreturnを禁止しているコーディング規約もあるぞ。
何らかの片付け処理が必要なものはデストラクタでやるようにしていても、
returnで抜けさせてくれないのよ。そんなだから、例外も投げるのは禁止されてる。
C++なのに・・・と激しく悶える。
>>372 return禁止
基地外じみてるな。
しょうがねぇから用もねぇのにフラグ変数増えてハマる・・・
規約を決めた根拠がわからん。
class CCard { private: Card card; public: CCard() { /* インスタンス生成及び失敗した場合の処理。 */ }; ~CCard() { /* メモリの解放 */ }; } CCard::CCard() { card = new Card[52]; } CCard::~CCard() { delete[] card; } OO的には普通こんな感じじゃないの?
老婆心ながら、ジョーカーの存在を忘れてるよ君たち。 カードの数は53でそ?
だってちちならべにジョーカーは使わないんだもん
>>374 それでgotoも禁止ならもうどうしようもないな
そこで、returnもgotoも使えない場合にはこんなコード。 bool func() { int foo; char buf[100]; FILE * fp; bool err = false; if (!err && (fp = fopen("foo", "w")) == NULL) { err = true; } if (!err && fgets(buf, sizeof(buf), fp) == NULL) { err = true; } if (!err && sscanf(buf, "%d", & foo) != 1) { err = true; } if (!err) { fclose(fp); } return err; }
return禁止なのは、C時代の名残りだね。 openしたものをcloseせずにreturnしたらヤバいでしょ。 returnと書くところで、それぞれcloseしたら、closeし忘れも出るしね。
382 :
379 :2005/07/19(火) 19:15:17
調子に乗って書いたらfclose()前にもチェック入れちまったよ。
それもそうだが、他にもツッコミどころが・・・ 普通は↓のようにやるだろ。 bool func() { bool bResult = false; int foo; char buf[100]; FILE * fp; if ((fp = fopen("foo", "w")) != NULL) { if (fgets(buf, sizeof(buf), fp) != NULL) { if (sscanf(buf, "%d", & foo) == 1) { bResult = true; } } fclose(fp); } return bResult; }
どっちを読んでも似たようなもんだ writeモードでfopenして何がしたいか良く判らん 参照側ではエラーの種類も判らんし、fooは使わんのか? #まあfcloseの返り値を見ないのは支持出来るにしてもだな
インデントが深いのも禁止という制限を設けてみる。 E-mailに貼られても7Replyまではクソビューアでも見れるであろう 72文字制限つき。
386 :
379 :2005/07/19(火) 23:23:11
>>383 いや、それだとインデント制限もある場合に難しくなる。
387 :
379 :2005/07/19(火) 23:24:45
>>384 わはは、最初はライトでサンプルを書こうと思ったのが途中で挫けてリードになったわけだ。
いいじゃん、察してよ(ぉぃ
>>385 たしか規格にで処理系はブロックの入れ子を最低15認識できないといけないと書いてあったはず。
となると逆に言えばそれ以上の入れ子のソースはやらないほうがいいと言うことだろう。
#インデント15はかなり多いと思うけど。
そういえば一行の長さは最低519byte以上を認識するべしとも書いてあったような ・・・んなもん書くもんか
どっかのスレで、一行数KBytesのコードを見たってコメントを見たことがあるが。
人間が書いたのではなく、 難読化のツールの出力だったりしないか?
>>388 8タブだとえらいことにw
>>389 標準的なBUFSIZ(512)-CR-LF-EOSで509バイトかと。
ポインタの話・・・
>>392 ポインタの話は今のままでしょうがないでFAじゃないの?
で、509バイトがどうかしたの?
>>393 519バイトはおかしいよね という話?
395 :
392 :2005/07/22(金) 21:50:33
タイプミスだと思ったんだけど、とりあえず突っ込み入れておきますた。 519で正しかったら・・・吊ります。
ポータビリティ性の問題だね - 8 nesting levels of conditional inclusion. - 8 nesting levels for #included files. - 32 nesting levels of parenthesized expressions within a full expression. This will probably occur when using macros. - 1024 macro identifiers simultaneously. Can happen if one includes too many header files. - 509 characters in a logical source line. This is a serious restriction if it applies after preprocessing. Since a macro expansion always results in one line this affects the maximum size of a macro. It is unclear what the Standard means by a logical source line in this context and in most implementations this limit will probably apply em before macro expansion. - 6 significant initial characters in an external identifier. Usually this constraint is imposed by the environment, e.g. the linker, and not by the compiler. - 127 members in a single structure or union. - 31 parameters in one function call. This may cause trouble with functions which accept a variable number of arguments. Therefore, it is advisable that when designing such functions that either the number of parameters be kept within reasonable bounds or that alternative interfaces be supplied, e.g. using arrays.
個人的に重要視してる。 80文字制限を批判する書き込みもあるようだけど、紙媒体等への 出力を考慮すると、やむを得ないと思う。 俺は紙使わないけど、検索できないし。 でも「俺が正義だ」コードは吐かないように努めている(はず。
>>397 流石、日本語をまともに使えない人は一味違うね。
何でそんなに・・・
紙に印刷すること自体が間違いだよ。 変なところでぶった切って見通しが悪くなる。 検索できない? そりゃ糞環境を改善して幸せになるべきだ。
主観のみの発言と言われてもしょうがないかな? 客観的な事例を挙げるとよいと思われ。
>>400 >俺は紙使わないけど、検索できないし。
これは普通の解釈をしては成り立たない文章なのだと思う。
おそらく、「俺は検索できないから紙を使わない」なのでないだろうか。
>402 ありがとう。その通りです。 漏れとしては他に解釈のしようがないと思ったんだけど・・・ それこそ「俺が正義」なのか・・・
俺は紙は使わないけど。検索できないし。 なら意味は通る。
>これは普通の解釈をしては成り立たない まさに普通に解釈しちゃダメだったね。
いや日本語としてはOKだと思う。 小学校で習ったことをがんばって思い出すと、 それは倒置法っていう奴らしい。
これからはなるべく理解しやすい発言を心がけるよ。 正直すまんかった。 紙媒体ではなく電子媒体または二次記憶媒体での文書保存おkで ISO9000取得しているところって多いのかな?
うちのISO9000の内部監査では、 監査員が見せてと言ってすぐに見せられれば電子媒体OKになってます。
某映画の様にzipドライブとかオープンリールでそのままは論外ってことだね
必ず紙媒体が必要だな。 電子媒体はマシンがとらぶってダウンしてたら見れなくなるんで不可。
じゃあ>408は?
>>408-410 thx
408は内部監査と限定してあるから、保存用は別ということかな。
設計審査とかのときに重いファイルを持ち歩かなくてよい、目で検索する必要がないなど、
紙より効率いいなぁ。
>>410 (一時的)保存媒体さえしっかりしていれば参照するマシンは何でもよいかと。
長期保存が問題になるような希ガス。
CD-Rに保存するとして、文書保有最低年数は保存データを保証するメディアでないとダメ
だろうし、数年後に読み取り可能なハードが存在するか?という問題もあるだろうし・・・
413 :
408 :2005/07/24(日) 21:05:39
ちょっと前まで保存用は紙でした。 最後に紙に印刷して倉庫にしまっていましたが、 倉庫から出してくるのが面倒なので、 後から参照するときも紙は使わないです。 んで、その先がアホな話しでして・・・。 紙に印刷して倉庫番に渡すという社内ルールはそのままに、 倉庫のスペース削減のために、紙ではなく電子化して保存するようになったんです。 紙で渡したものをスキャニングして保存、紙は廃棄。 倉庫から出してというと、紙に印刷して渡してくれる・・・orz ちなみにうちはCD-RはCD-ROMのマスターとして業者に渡す時だけで、 基本的に保存はMOを正副2枚ずつ保存するようになっています。
CD-Rなら良いのかもね。 うちはMTだからダメなんだよ。 (大型コンピュータの磁気ディスク装置にかけるなんてすぐにはできない) そういや文書はマイクロフィルム化してもよいことにはなってたな。
なんかもう激しくスレ違いですね
スマソ
>>413 ワラタ
MO二重化はOKか。
参考になります。
>>414 マイクロフィルムは耐用年数が非常に長いみたいね。でも手間が・・・
>>415 夏厨が読んだら少しはタメになるかと。
>>417 うちは納品物は全部正副の2部づつだけど?
電子媒体に限らずソース(紙媒体)、仕様書にいたるまで全て。
品質管理の一環で?
品質管理とは関係なく常識かと。
話の流れからして、品質管理上必要な文書長期保存の媒体がMO一枚では心許ないので、 正副の二枚に保存することによって電子化できたということだと思ったが。 それはそれとして、 納入物件に紙媒体のソースがあるというのが気になる。
話の流れからして、品質管理上必要な文書長期保存の媒体としてMO一枚では心許ないので 正副の二枚に保存することにより電子化できたということだと思ったが。 それはそれとして、 納入物件に紙媒体のソースがあるというのが気になる。 もしかすてF通?
どうでもいいやんそんなこと
別に不実に限らんだろ。
富士通のCMをやっていた工藤静香の曲の歌詞に、 「不実です」というのがあったが、「富士通です」に聞こえたな。 前後の詩の文脈とも相まって、えぐい話だ。
いや、でも電子媒体のみで運用できる? もし印刷したりして持ってたら版数アップとかで 最新版と内容がずれることがあり、監査で引っ掛かるぞ。
427 :
パラドックス :2005/08/09(火) 23:02:01
C++ならあるんだよな>>int &a さて .cppで int* aとはどういう違い?
別名とポインタ
429 :
デフォルトの名無しさん :2005/08/10(水) 15:14:25
別名はポインタ型の変数に,自動的に*をつけて 逆参照していると思っていいのではないかと思う. foo (int& a) { a = 1; } は, foo (int* a) { *a = 1; } と同じ.別名だとa++みたいな ポインタ操作ができないからこちらの方が安全.
最近は、「別名」なんてわけのわからん訳をするのか?
前橋って人がある本で『C++における参照は本来「別名」(alias)とでも呼ぶべきものです』って書いたのが原因かも まぁこれが何処か別のところからの受け売りである可能性も否定できませんが
428につられて書いたけど, たしかに, 上で書いた引数の例だと,別名って言わずに 参照渡しと言って,そのまま変数を参照って 言うことが多いね. でもこれはちょっと混乱の元かと. 普通の変数であってもデータを参照しているわけだし.
初心者に言う時に良く言うヤツ多いな、別名って
参照って単語が使いづらいんだよ Cのときは「ポインタを使って参照する」とか 言ったりしてたのに参照そのものが出来たら 今まで言ってた参照をなんて言いかえるのか
だがポインタを使って値を参照することに変わりは無いわな
>>435 だから、参照に参照という名前をつけてもいいんだけど
それだと参照するときに参照という単語を使うと
参照がダブってしまうので今までのただの参照と
誤解を生むんだよ
参照のオンパレードだな
そこで意味も無くリファレンスとかエイリアスとか横文字を持ち出してお茶を濁すのはどうだろうか?
初心者を煙に巻く以外の意味は全く無いな
初心者を煙に巻ければそれで十分。 煙に突進してくるくらいの気概の無い初心者を振り落とせるからな。
たしかに参照って言葉は用語として用いるには意味が広すぎて嫌だな… 「別名」のほうが混乱がないと思う…
しかし別名という考え方が一般化すると、次は普通に定義された変数が本名とか呼ばれそうな予感。 ・・・でも、そんなに弊害は無いかな?
別名とくればそりゃ普通に本名だろ
仮名・堂島 とか
とんでもない方向に… 「アドレスを示すポインタ」が基本だろ? ポインタはポインタ。 ホワイトボードに書かれた項目をレーザーポインタで指し示す場合、 参照やら別名とか岩ネーだろ。 要は、アドレスを表すのか、アドレス内の値を表すのかって事だけなのに、、、 お前ら、初心者を振り回すのに必死だな。
ポインタはアドレス
俺の会社では、レーザーポインタとは呼ばずに激光指針って呼んでるよ。
俺はレーザーポインタって呼ばずに赤い点って言ってるよ
>>445 アドレスだけがポインタだと思うなよ小僧
なんだよC爺
>>450 ポインタだけがアドレスだと思うなよ、の間違いですか?(・∀・)ニヤニヤ
おまん子が変数 おちん歩がポインタ { おまん子 小倉優子,谷亮子; おちんぽ * 俺; 俺 = &小倉優子; ASSERT((*俺)(スコスコ)) 俺 = &谷亮子; ASSERT((*俺)(スコスコ)) ←ここでエラー }
楽しいか?
ポインタだろうが参照だろうが吐かれるコードは一緒だろうが。 アプリ屋ばっかだな。
誰に対してのレスだ?意図も不明
どっちでも同じってことだろう。 が、ソース上の違いが重要なのでは?
>>458 ファーム屋にはそこがわからないんだよ
良くも悪くもアセンブラの延長としてしか
Cを使ってないからな
C:中級言語 C++:中級言語としても使える超高級言語。 当然、基本クラス設計者は神のように下々を見渡せる必要があるが、 んなクラスは見たこと茄子(単純なのは除く)。 言うまでもなくMFCなんぞ論外。 C#標準化って何?
高級言語の意味を理解してない馬鹿
>>459 PCの発展や最適化技術の発達によりパフォーマンスよりもソースの可読性の方が重要視される場面が出てきたということさ
>>461 禿同
……けど、C はかなり低級よりな高級言語だぞ
「アセンブラめんどいから強力なマクロ作りまスタ。」が、C言語なんだから、おおむね正解。
C言語作ったのって「UNIX移植するのめんどいから」ってのが理由じゃなかったっけ?
そう。 動機がその程度の言語だから いい加減な作りがあちこちにあるのは当然。 なのに開発言語としてメジャーになってしまったのが コンピュータ界の悲劇。
他の言語開発者みてるとたいてい理想ばかりが先走って実用性は二の次三の次なヤシばっかなのが不幸をさらに加速させたよな
467ではないが一つあげられるのは演算子の優先順位。
>>467-468 そりゃOSを書いてる言語だから、メジャーになるだろうよ。
Cを習得しないと、目の前のマシンにUNIXを移植することができないし、
改変することすらできないわけで、必修言語なわけですよ。
>>470 いい加減と言うより、自分が覚えられないだけじゃアルマイカ?
>>471 C使いの誰しもがUNIX野郎だとは思えないけどna
つか,なんでOS(ry
単にコンピュータとの親和性が高い(アセンブラに近い)という点に尽きるだろ
それだけ
演算子の優先順位がいいかげんって、どのへんがいいかげんなんだ?プ
>>475 それは ++ の方が優先順位が高いが、単に ++ が元の値を返す性質があるだけ。
ビット演算子の優先順位が比較演算子よりも低いのはおかしい。
論理演算子が存在するのに、比較演算の結果をビット演算する用途なんてそう頻繁にはないだろうが・・・。
論理xor演算子を導入した上で、ビット演算子の優先順位は上げるべきだった。
あとは散々外出だけど、ポインタ参照演算子は前置ではなく後置の単項演算子にすれば文法がかなりシンプルに なるのに、前置したため話が面倒になってる。 前置の良い所はメンバポインタを記述するのに括弧がいらないことくらい。 あとC++の話になるけど、テンプレートの括弧に<T>をつかってしまったこと。 × TemplateClassA<TemplateClassB<int>> ○ TemplateClassA<TemplateClassB<int> > このスペースがキモイ。↑ まぁ探せばまだまだあると思うが。 根源的な話をすれば、LL(1)文法にしなかったという点で、リッチーは言語設計者としてのセンスが無い。
関数の()の最初と最後にスペースを入れる俺にとってはそんなスペースキモくも何とも無い てめぇの趣味だけで語ってんじゃねぇよ
文法の話と読みやすさの話を混同しないようにしよう
>>478 関数の( )の前後はスペースの有無にかかわらずエラーにはならんが、多重テンプレートはスペース入れないとエラー。
関数はお前のような趣味をする余地があるが、テンプレートは趣味が許されない。しかもキモイ。
< や > を多用しすぎなんだよな。
a->b とか、 a-->b とか、 a>-b とか、 a--->b とか・・・
まぁ、キモイ=いい加減 というのは成り立たない。 481はキモイ
キモイキモイ言ってるだけかよ481
記号の使いまわしが 気に入りません カーニハンに謝罪を、そしてリッチーに賠償を要求しましょう
チョンうざい
>>475 そんな無意味なコードを書くな(w
せめて別の変数に代入すれ。
>>487 (a--) > b デクリメントと比較演算子
a > (-b) 比較演算子と単項マイナス演算子
(a--)->b デクリメントとアロー演算子
あぁなるほど、ってデクリメントとアロー演算子とか、普通()つけるだろ・・・
わざわざ分かりにくくて一般的でもない事例をあげて 使いにくいとほざけばいいと思ってる
ポインタの本を10冊以上買って読んでみたけど さっぱりわからん。 なんかこう、フィリーリングが合わない。 アセンブラはわかるのに。 たぶん同じことをやるのに何通りもの書き方があるせい。
フィリーリングとはなんですか?
auth! フィーリングだったぜ。 カナ打ちだからゴメンな。
カナ打ちだから
>>491 お前なりにポインタについて解説してみな
そうすりゃどこがおかしいのか見えてくるから
>>490 葉外道。いくらなんでも変換ミスったようだ
>>491 >アセンブラはわかるのに
で、ポインタはわからんと・・・
釣られてしまつた orz
>ポインタの本を10冊以上買って読んでみたけど ホホゥ
499 :
497 :2005/08/21(日) 02:02:04
このスレ パスカル使い多くね? Oberon実務で使ったことある人いるのかな?
>>473 話の流れを嫁。
ついでに歴史の勉強もしろ。
ということにしたいのですね?
はい、ということにしたいのです。
かのようなこと、某の一存では決めることができませぬ
>>1 おかしいだのどうのこうの言っても何もならんのにな。
現実の言語仕様に黙って忠実に従うことだけを考えてきたが。
お主は、英語でも文法だの活用形だの発音だのおかしいと言ってる人物ですの?
それよりも$記号て何ですの?それとCなのに何でC++のコメント使ってますの?
原理主義者ですか?w 俺は++でも/*使っちゃってるけど、C99では//は本則ではないのん? (てめぇで調べろ→漏れ /*で書いとけば無問題なのでどうでもいいか・・・
まあ、たしかに
>>1 は自己中心的なナルシストだけどさ、Cで//をコメントとして用いたら、コンパイラーが怒るでしかし。
C99から//コメントアリだよ
俺がコメント書くと十中八九複数行だから/**/で書く
// で書いとくと、実験中に /* */でコメントごとコメントアウトできるから 便利だ。 さらにそれをもコメントアウトするときは #ifdef 0〜#endif だ!
>>509 #ifdef 0
でもいいけどね・・・
#if 0
のほうが
あ、そうか
>>510 の方がいいな
0がすでにdefineされている可能性をわすれちたよ
ただしくは「#ifdef <IDENTIFIER>」か >gcc test.c test.c:3:8: macro names must be identifiers
#defundefun
515 :
デフォルトの名無しさん :2005/08/24(水) 04:46:09
Cの本質的に糞なところはポインタの文法ではない。 文字列型をサポートしないのに文字列リテラルをサポートしてしまったことだ。 この安易な機能追加による不統一感は耐え難いものがある。
メモリ管理をしない言語っていうのも、どうかと思う。
禿同
521 :
デフォルトの名無しさん :2005/08/24(水) 17:49:37
C言語の欠陥は・・・整数除算と浮動小数点除算の区別がわかりにくく、明示させるのも面倒なことかな。 Pascalみたいに、別の演算子にすればよかったのに。 あと、浮動小数点から整数への自動型変換も迷惑。情報が欠落する方向へ勝手にデータを変換するな。
>>521 Pascalをやっているとそのように思うのはもっともだけど。筋が違います。
Cは「プログラマは間違えない」という前提で設計された言語だから
でも浮動小数点から整数への暗黙の変換は確かにどうかと思う。
警告が出るコンパイラを使えばいいじゃない。
>>521 =523
> でも浮動小数点から整数への暗黙の変換は確かにどうかと思う。
それ逆だから。何の事言ってんだ?
そりゃ暗黙の変換以前の問題
つーか、小数の扱えないものにわざわざ小数型を持ってくるのが悪い
529 :
デフォルトの名無しさん :2005/08/24(水) 18:51:10
>>522 「プログラマは間違えない」という前提の代償が簡便な記法になるならともかく、
整数と浮動小数点数の型変換は除算の時いちいちキャストしなくてはいけなく、
逆に記述が面倒になっているが。
531 :
デフォルトの名無しさん :2005/08/24(水) 19:02:14
int m=9,n=3; int a = m/n; float b = (float)n/m; いちいちキャストするの面倒だとは思わんか? それなら、 @とかを整数除算演算子とかにしちゃって、 int m=9,n=3; int a = m / n; // これはエラー int a = m @ n; // これはOK float b = n / m; // これはOK float b = n @ m; // これはOKだが、b=0.0 となる。 とかの方がスッキリすると思わんか? まぁ直感的に@が除算に見えない、という感覚的な問題は別として。
だから、んなーことない って、何言ってんのこの池沼
池沼だからしかたがない
534 :
デフォルトの名無しさん :2005/08/24(水) 20:15:33
Cが嫌なら使わなければいいじゃない。
出た。オコサマの論理。
だれも「前提の代償が簡便な記法」とは言っていないし
537 :
デフォルトの名無しさん :2005/08/24(水) 20:47:51
int a = 1 / 3 * 3; これが a==1 になることってありえる?
学生の作ったバグ入り最適化コンパイラならありえるかもな
>>538 ありがとう
おれが作ったのはバグ入り最適化コンパイラってことでFAみたいだ
540 :
デフォルトの名無しさん :2005/08/24(水) 21:07:52
>>539 いや、藻前が作ったのは有理数型をネイティブサポートした、誰も必要としていない高性能コンパイラだ。
確かにいらねーな。ライブラリで使えるならいいけど。
>>537 今のコンパイラーは、最適化するから、 /3 *3 の部分が無くなるよ。
>>537 普通の数学の決まりに則ればa==1こそ正しいんだけどな
544 :
デフォルトの名無しさん :2005/08/24(水) 21:44:11
>>542 それは…つまり…
a = 1ってことですか?
数学的には a = 1/3*3 1 = ----- 3*3 = 1/9 が正しい
何この池沼546?
>>542 いや、1 / 3は整数型同士の演算だから0にならないといけない。
549 :
デフォルトの名無しさん :2005/08/24(水) 22:30:04
浮動小数点でもマシンイプシロンを考慮しなくてはいけない。
>>542 それが最適化しても a==0 になるんですちょ
実験してみれば分かる
int a = 1 / 3 * 3; aの値は? (※乗除算の優先度は同じ) (1)数学的 虚数がない限り全ての数は実数計算。 1/3*3 = (1/3)*3 = (1*3)/3 = 3/3 = 1 (2)整数型 Cの基準どおり行われる。手前から順に計算。整数なので小数点以下は切り捨て。 int a = 1/3*3 ↓ 1/3=0.33333・・・ → 0 0*3 = 0 a=0 もちろん、こんなことをするのはプログラマーのミスと言われても仕方がない。(意図的にやっているのでなければ) なぜCが高級アセンブラといわれるかを分かってない発言多すぎ
ネ(ry
内心Cがメジャーになったのが気に入らないってのが否定派の深層心理。
554 :
デフォルトの名無しさん :2005/08/24(水) 23:06:00
別に気に入らない訳でも否定する気も無いけど、Cにあまりにも欠陥が目立つな、とは良く思う。 少なくとも熟慮の上で設計されたエレガントさがCには感じられない。 なんとなく思いつきで作った言語って感じが否めない。
実際、最初はUnixを書くために作ったらしいしな。 そう考えればCはアセンブラに比べれば格段にましだ。
556 :
デフォルトの名無しさん :2005/08/24(水) 23:11:48
>>555 >実際、最初はUnixを書くために作ったらしいしな。
まだそんな話を信じている馬鹿がいたのかww
557 :
デフォルトの名無しさん :2005/08/24(水) 23:25:32
考えてみれば、分数を表現できないのがおかしいよな。 なにか数式言語をネイティブサポートすれば解決。
構造体があるじゃない
>>556 色んなUnixの歴史を書いた本に書かれてることなんだけど、あれは冗談だったのか・・?
>>556 ええっ嘘なの?
コンピュータ界の歴史が変わる大事件だよ
ソースキボンヌ
ヒント:Unixも開発段階からそう呼ばれたわけではない。
当時はUNIXとは呼ばれていない → Maltics が頓挫したあと、まだ Unics と呼ばれていた時代か? 新規ではなく、既存のOSを改良するために開発された → 移植性を上げる為、極力アセンブラを排除するのが目的
>>563 それは私の知識と違うなw
Malticsのアンチテーゼの意味合いで新規に開発された。最初はアセンブラが沢山。
移植性を付加するため、アセンブラ部分をCに書き換えた。
>>563 ,564
×Maltics ○Multics
トリビア:
何でもできることを目指したMultics(<Multi)のアンチテーゼとして
開発されたことからUnics(<Uni)と名づけられた。
僕は配列として使うポインタ型作るときは int a[]; と宣言してアドレス演算子を使わないようにした。 ** の重複を回避するためなら a[0] とかいうアクセスもした。 これで掛け算の * と変数の * が混在しなくて済む。 a->b とするよりも a[i].b としたほうが、 デバッグ中に何番目のデータを処理してるか、 すべてのデータを処理したかどうかがはっきり分かるようになる。 データ依存のバグが出る場合はメリットが大きいよ。
567 :
デフォルトの名無しさん :2005/08/25(木) 05:14:07
プロセス間などのメッセージボディーのデータ内に、生のポインタ渡すのもキメエよな。
Windows3.1に謝れ
なんだ脳内か
>>566 仮引数でないときにはint a[]はポインタ型にならないのだがそのときの宣言には * がいるだろ。
ハンガリー様でいいじゃない int iMonar ; int *ipMonar ;
>>572 そこpiMonar。
自己流なら気にしないでおくが。
piMonyar
piMomi
>>566 別に int *aで宣言してもa[x]で使えるわ
ハイハイワロスワロス
579 :
デフォルトの名無しさん :2005/08/28(日) 01:37:57
>>1-2 吹いた
余計にややこしくしてるし
ポインタとアドレスの区別くらいしような
定義と宣言の区別がついていないヤツ大杉。
最近定義と宣言が区別できるようになって大喜びの
>>580
ハッ
何この流れ。
今時Cなんて資格取得の為にリア厨が勉強するくらいのもんだからな
Cじゃなきゃ取れない資格って何?
C出来る人エキスパート最高! な時代がきたらいいなぁ
589 :
デフォルトの名無しさん :2005/08/29(月) 15:34:53
いやとっくに過ぎてるんですが
Cさえあればずっとやっていける そう思っていた時期が俺にもありました
C言語覚えたら潰しが利くって言ってた奴でてこーい
C++, C#, Objective-C Perl, PHP, Java...csh(w オレの知る限りだとこの辺りは文法が近いので乗り換え自由だと思うのだが。
君はどの言語でもFORTRANが書けるんだね
ほとんどの言語はC言語のライブラリの上で動いていて 現状そこら辺を隠蔽した言語はパフォーマンスの壁にぶつかっているので C言語も多少はやっておいて損はないとおもうけどなぁ・・・
パフォーマンスの壁…ってんなもん意識する機会なんて極わずかだよ…
俺らゲーム製作者には重要な壁だ
多少やるぐらいで埋まる速度差ならおまえが悪い
>>595 ならなぜJavaがNIOというライブラリを追加したのか説明してくれ
599 :
デフォルトの名無しさん :2005/08/30(火) 00:39:00
Cってプログラミングの基礎だからさー Cをやってから他の言語をやると割りとすんなり覚えられる 逆に他の言語をやってからCをやってもかなりハードルが高いぞ だいたいポインタで躓く プログラマを語るんならCは必須だと思うな まあもちろんCだけではだめだけどな
C言語の習得ごときにたいそうな誇りを持ってるようだな
ポインタなんて時代遅れ
と、ポインタに挫折した人が申し上げます。
どんな言語でもポインタがわからなきゃ内部でC言語の関数を使うライブラリ呼び出すときに難儀するだろうに・・・
どっちかっつーと関数を作る時に混乱するんじゃね? 呼び出す時なんて&つければいいだけじゃん
>>599 俺はポインタで躓いたあと、
スクリプト言語と浮気しているうちにふっとポインタの使いかたが分かるようになった
浮気者! _, ,_ パーン ( ‘д‘) ⊂彡☆))Д´)
>>605 スクラブと言語ってポインタの概念ないじゃん
どうしてふっとわかったのか教えて
608 :
デフォルトの名無しさん :2005/08/30(火) 21:41:02
>>605 文尾が不完全だぞ
× 分かるようになった
○ 分かるようになったつもりだ
609 :
デフォルトの名無しさん :2005/08/30(火) 21:43:38
>>601 CPU,MMUの動作原理を知っていての発言なら許す。
でもCPU(x86系)だと、C言語にあわせた新設命令とかアドレッシングとか追加されたよね。 高級言語を効率的にコンパイル・実行できるようにマシン語を追加するなんて逆転現象だ。
>>611 CISCだからね。
っつうか、Cの文法(++とか)は、68系のCPU(MPU?)に最適化された言語なんだよなぁ・・・。
68系? 86系じゃのぉて?
Cの出自を知っている人間なら釣られない
>>612 INC命令がADD命令より高速だったのは、x86だけじゃなかったっけ?
Pentium系のμコードとかout of orderとかでこれは崩れたわけだけど。
>>615 Z80と68kに限った話ではincの方が速い
Z80 INC A
68k addq.l #1,d0
>>612 と
>>615 のつながりが良くわからないけど、
昔のヤツはどれもincが速いんでないかい?と思った。
MIPSとかに代表されるRISC CPUにはそもそもINC命令はないし、 基本的には命令に速度差はないね。
つーか、マイクロプロセッサ以前からCはあるわけだが。
逆だね。68KがCエンジンを目指したんだな。 いい石だね。Big endianness(綴り間違ってたらすまん)は最低だけど。
綴りスゲー間違ってる(読みでも)けどそれは置いといて なんで? LANなんか伝送路はすべてそうなってるじゃん。 逆にx86の方がサイテー。(いちいちひっくり返さなきゃならん)
エンディアン論争を始める気か
エンディアン嘘つかない
アセンブラ使いはリトルエンディアン支持 高級言語使いはビックエンディアン支持 が多いようだ
両方から選べるアレでいいじゃん。アレ。
>>624 そう?
俺アセンブラ使うけど、出来りゃビッグエンディアンの方が良いと思ってるよ。
でもZ80から始まってx86系使うことが殆ど。MIPS,ARMとかも使うけど。
どういう理由なのかな?
>>626 たとえば16bitのデータを8bitのデータに変換する場合にビックエンディアンだとシフトする必要があるとか
>>627 そんなことに不便は覚えんけど?
リトルエンディアンでも上位8bitは0にしなきゃいけないわけだし。
(シフト命令とAND命令とそんなに差があるか?)
そんなことより外とのインターフェースをとろうとすると
x86はいやらしいぞ。RS232Cの頃からLANまで結構バグった。
(って言ってもすぐ判明する単純バグだからデバッグ初期ですぐ潰せたけどね)
エンディアンがらみのバグが出るコードなんか書いた事ないなあ どんなアホなコード書けばエンディアンのバグ出るんだか教えてくれ
例えば、 先頭にパケット長が入って、それ以降データ。 とかで思わずそのままWORDとかDWORDとかで計算したまま入れちゃうみたいな感じ。 (もちろんすぐ気づくよ)
俺の頭の中で、小さいインディアンと大きいインディアンが闘ってるのはなぜだ。
x86系は8/16bitアクセスに優れてるけど、CPUの歴史と特性のせいだな。
>>629 文字扱う関数がなぜか文字データ型をint
>>629 char *p = xxxx;
short s;
long l;
s = *((short *)p)++;
l = *((long *)p)++;
ダメダメだとわかっていてもつい。
つーか各方面で不統一だから混乱するだけの話ジャマイカ 俺達人間インディアンだから仕方ないさ
一般ファイルや通信プロトコル、その他特にCPUアーキテクチャに無関係なフォーマットでは バイナリは、ビッグエンディアンに統一されてると思うがなあ。
>>638 そうだな。
問題視されるのは、あまりにも無作法なコーディングが氾濫しているって事だろうな。
多バイトコード文字を正しく扱えない西欧由来のコードもなんだかなーだけどさw
PDP-11
通信がビッグエンディアンなのは、 TCP/IPが開発された時に使われていたコンピュータがビッグエンディアンだった というだけのことだと思うよ。
>638
>642に同意
そういう環境(ワークステーションとかサーバーとか)で多く使われているCPUが
ビッグエンディアンで、開発者自体がそれに慣れていたからだと思う
ただ歴史的事情から"正統"といわれてもなぁ。
ttp://www.atmarkit.co.jp/aig/01xml/endian.html ttp://www.google.co.jp/search?sourceid=navclient&hl=ja&ie=UTF-8&rls=DVXA,DVXA:2005-16,DVXA:ja&q=%E3%83%93%E3%83%83%E3%82%B0%E3%82%A8%E3%83%B3%E3%83%87%E3%82%A3%E3%82%A2%E3%83%B3+CPU リトルエンディアン
8,16,32,64といったビットの桁拡張をアドレスに沿って伸ばせるので(過去のCPUとの)互換性を取りやすい
バイナリ上位互換の拡張を繰り返しているCPUであることが多いため命令長が固定できない。
・x86系(Pentium,Athlon,他)
ビッグエンディアン
数値の並びを感覚的に出来る(上の桁を先に書く、という自然の感覚。最初のころはマシン語で直接書いていたことから考えれば・・・)
命令長を固定できる。(こっちの方がエレガント)
・モトローラ系(MC68k,PowerPC)
・SPARC
バイエンディアン(ビッグ/リトル切り替え可能)
・MIPS系(R3000,R5900(PS2のCPU、EEの俗称),R10000)
エンディアン論争はやめーい
one little two little three little endian 〜♪
>>643 ビッグエンディアンかどうかと命令長が固定かどうかは無関係じゃね?
つまり要約するとリトルエンディアンはダメダメで ビッグエンディアンは素晴らしいって事だよね?
つか、パラメータの類を通信する時に、数値部分をバイナリで送るってプロトコルなんてあるのか? 最近の通信プロトコルは、アスキーテキストが普通だと思ったが・・・。
>648 それはOSI階層モデルで言うところのレイヤーが全然違うのだが。 ここで話が出ているのはTCP/IPでネットワーク層及びトランスポート層 アスキーテキストがまともにまともに扱えるのはセッション層以上じゃないか? Ethernet(Physical)->EthernetProtocol(DataLink)->IP(Network)->TCP(Transport)-> //ここまでバイナリ HTTP(Session)->HTML,MIME(Presentation)->IE(Application) //こっちはテキスト可
>>648 データ通信またはデータ通信で機器制御するソフト作ったことあるのか?
HTTPみたいな汎用なやつじゃなくって?
>>648 お前さんはTCP/IPも使ってないのか。
アプリ層でもバイナリデータなんていっぱいあるじゃん。 大体、アプリでフォーマットを決めるんで、それこそ無数にある。
SOAP以外は全部糞
DCOMは?
糞
DQNは?
目撃
>>1 単純な変数だけ考えると若干不自然に感じるかも知れないが
ある構造体の宣言 その構造体変数,その構造体変数へのポインタ;
って一箇所にまとめて書けるメリットは理解できるだろ?
>>660 何を今更。
つーか、あんたは>1を理解できてないだろ。
そもそも>1の書き方もおかしいんだよ。 int* p ; // 「int値を持つポインタ変数」の宣言 p ; // 「int値を持つポインタ変数」の内容(=アドレス) *p ; // 「int値を持つポインタ変数」の内容が指し示す場所の値 int n ; // 「int型変数」の宣言 n ; // 「int型変数」の値 &n ; // 「int型変数」が格納されている場所へのポインタ ポインタ宣言を「int *p ;」と書くからおかしく感じるだけで、「int* p ;」と書けば 「int値を持つポインタ変数」である[p]の宣言,という自然な解釈ができる。 C++ではこの記法を標準としているくらい。 ちなみに上の記法からすれば↓はおかしいことになる。そうするならポインタ宣言は不要。 int$ p ; // 「int値を持つポインタ変数」の宣言 $p ; // 「int値を持つポインタ変数」の内容(=アドレス) p ; // 「int値を持つポインタ変数」の内容が指し示す場所の値 int n ; //「int型変数」の宣言 n ; // 「int型変数」の値 $n ; // 「int型変数」が格納されている場所へのポインタ
ところがだ、 int* a, b ; と書くとどーなるかな? typedef int* int_ptr ; int_ptr a, b ; とやらないと、大変なことになるよ。
>>662 int *p;という書き方は式内で*pと書くとint型になると読めるという利点がある。
俺は一つの宣言に一つの変数で書くからint* a, b;なんて問題は起こらない
666 :
662 :2005/09/17(土) 11:10:50
>663 それは前から知ってる。だからポインタ宣言は1つずつ書くようにしてる。 >664 それ誤解の原因だから。関数宣言、定義の引数、戻値がその形式で書かれて過去に迷ったことが何度あったことか。 char *strcpy(char *s1,char *s2) と char* strcpy(char* s1,char* s2) なら、下の方が自然だと思う。
そんなに迷う宣言はtypedefしろよ。
わかった、Javaを使えばいいんだ。
それは逃げているだけ。
>>666 俺は上の形式を使ってるな。
その方が自然に感じるので。
まあどっちにしろ、言語がその表記を許してるんだから好き好きで良いと思うんだが。
俺は、 ポインタ変数とtypedefした型変数とは別だという認識になるな。 (実際には同じ動作でも) 従って int *p; int **p; int ***p; int_ptr p; int_ptr *p; int_ptr **p; という書き方になっちゃう。
>>671 Windowsのポインタでは型名にPが入る。
ポインタのポインタならPPとなる。
int *p;
は、あくまでint型の型定義であって、*pとか**pとかはpの属性って感じるなあ。
>>672 バカ?
int *p; int* p; 漏れはどっちでもいいと思うが、一方が「自然」で他方が「不自然」と感じる人もいる。 「不自然」な記法が許されている事が「文法がおかしい」の根拠になるんでないの?
Pascalみたく、変数宣言で識別子と型名の間に区切り文字を入れるかい?
全部参照にすればいいんだよ int n = new Int(1);
型宣言を根本的に誤解している連中が集う集会があると聞いてやって来ましたが、もうお開きでしたか・・・。
679 :
デフォルトの名無しさん :2005/09/18(日) 04:44:57
>>674 オマエこそ馬鹿だろ。
ポインタの型なんか関数に渡してしまえばどんな型にでもされちゃうのに意味ないだろ。
型に無関係に関数組めるのがポインタとキャストのいいところなのに、
そういうプログラム作ったことないんだろうな。
int *p でも int* p でもなくて int * p と書けばいいじゃない。
>型名にPが入る
これってつまりは
int_ptr
ってのはダメで
pInt
にしろってことを言ってるんだよね?
それと今議論してるのとどういう関係があるのかなあ?
それがわからんし、
さらに
>>679 がそれの何処に突っ込んでバカ返しをしてるのかも
さっぱりわからん俺ってきっとバカなんだろうな。
すまん。上のは
>>679 に対するレスで、
>型名にPが入る
ってのは、
>>672 が言った言葉。
さらに、int_ptrってのは別に
>>671 が言ったってわけじゃなくて
その前の
>>663 が言った言葉を受けていると思う。
>型に無関係に関数組めるのがポインタとキャストのいいところなのに
これも論点が完全にズレまくってる言葉だよなあ?
いったいこれから int* p;なのかint *p;なのか、はたまたどっちでも良いのか、
どっちもダメなのか全然導き出せないや。
俺の認識
int*p; //これはint型の定義
int**pp; //これだってint型の定義
int_ptr n; //これはint_ptr型の定義であり、上のint*p;とはまったく無関係
したがって代入は
n = (int_ptr)p;
p=(int*)n;
とcast変換が必要
こういう感じ方だと
int *p;
の方が自然だと感じる。
683 :
デフォルトの名無しさん :2005/09/18(日) 08:13:26
>>681 ばかじゃねーの?
int_ptr が * を書かないために使うのなら、
int_ptr* なんて宣言したら意味がなくなるだろと言ってるんだよ。
せめてint_ptrptr くらい書いてくれよと。
その程度のことも読み取れないのにSEになんて・・・・・
あ、ここは死ぬまでコーディングするスレだっけ。
>>682 >>型に無関係に関数組めるのがポインタとキャストのいいところなのに
>これも論点が完全にズレまくってる言葉だよなあ?
int *ip;
long *lp;
ip は intで lpはlongという認識らしいが、変数宣言したスコープ内だけの話だから、
同じ関数に渡せば二つは同一だと言いたかったんだが。
( ゚д゚)ポカーン
685 :
662 :2005/09/18(日) 09:49:54
自分が "型名"+'*' "変数名" に拘るのは、変数でやり取りされている内容、つまりあくまでポインタはアドレスをやりとりするもの という認識だから。下のレスと合わせてアセンブラの感覚で使っているということでもある。 char *strcpy(char *s1,char *s2); //これだと”*変数名”で値渡しに見えなくもないので慣れないと判別しにくい char* strcpy(char* s1,char* s2); //これなら"変数名"でアドレス渡しであることが判りやすい typedef int* pInt; int *pI_a; //int型の"*pI_a"に見えなくもない int* pI_b; //int値を指すポインタの"pI_b" pInt pI_c; //pInt型の"pI_c"で、上2つとは別の型。アドレス渡しを強く意識しないなら値渡しみたいに見えて良いのかもしれない。 >679 >683 自分もキャストはよく使うけど、使いすぎて型宣言の意味がなくなるとデバッグしにくくないか? (だから自分は void* と char* 位しか使わない) ついでに関数のプロトタイプ宣言の意味まで無くしてどうするんだよ。 (引数がvoid*型で宣言されてるなら確かにそうなんだけど)
>>685 >ついでに関数のプロトタイプ宣言の意味まで無くしてどうするんだよ。
なんでそんな風に思うか分からないね。
>値渡しに見えなくもないので
宣言時と使用時はまったく違うわけで、
使用時に勘違いしなければいいわけで。
アドレスの値なんてものを扱えるってのは もはや低級言語なんだよ。ポインターなんて使わず リファレンスを使おうぜ。 っま、低級な言語ほど実行速度が速いのは認めてやるぜ!
一回でも自分で言語を設計してみるとCのうまさが理解できるかも 式(実行文)と宣言とで同じ表現が使えるとか ポインタ型を別途用意する必要がないとか PL/I辺りと比べるとその差がはっきりする 見事としかいいようがない
>>682 > int*p; //これはint型の定義
ええーっ
型とは何か? という話になるけどさ、
自分の理解では、
たとえば
int* p ;
と宣言した時に、スタックに割り当てられた領域に入れることができるもの
ということだから、
int* p ;
の型が何かと聞かれたら、ポインタ、だと言う。
どういったポインタなのかと聞かれれば、intの変数を指すのに使うポインタだと言う。
「intの変数を指すのに使うポインタ」 が型の名前だ
なんか一人だけとんでもなくズレた奴が混じってるな。 本人がマジにそれに気づいて無いだけに不憫だ。
まあ要は動きゃいいのさ。 Cはプログラマの手抜き・知識不足を かなり許容してくれる素敵な言語だ。
>>682 >したがって代入は
>n = (int_ptr)p;
>p=(int*)n;
>とcast変換が必要
ごめん。キャスト無しで gcc に噛ませたけどワーニングすら出なかった
そういえば 「 typedef int *int_ptr; 」 とは書くけど 「 typedef int* int_ptr; 」 と書くのはあまり見ない気がする
「 typedef struct tagStruct { /**/ } STRUCT, *LPSTRUCT; 」 に見慣れているから錯覚しているだけか?
うえ〜ん。 俺、 LPCSTR * とか使ってるよ。 これは、きっとLPCSTRSTRとしなきゃならんのだろうな。
LPCSTRSTR -> LPPCSTRだろが。
>692 逆。手抜き・知識不足によるバグが出やすく、デバッグしにくい言語。 ポインタ使ってもアセンブラよりはマシという程度で、自動GCはしない、 スタックオーバーフロー監視機能も実行ファイルには付かない。 メモリ管理も甘いのでOS側で管理していないとバグった時に危険。 >693 mingwでこれ通したけどエラーは特に無し。 #include <stdio.h> #include <windows.h> typedef char* lpChar; int main(int argc,char* argv[],char* envstr[]) { LPSTR lp_a;lpChar lp_b;char* lp_c="test1test2test3"; lp_a=lp_b=lp_c; printf("%s,%s,%s",lp_a,lp_b,lp_c); return(0); }
697 :
693 :2005/09/19(月) 00:05:50
あ、682 と 693 は別人なんでよろしく
>>696 GCなんて必要ないって。
メモリが歯抜けになるのは、メモリ管理のライブラリがお粗末なのさ。
スタックオーバーフローが検出されないのはOSがしょぼいから。
Windowsならちゃんと例外になるよ。
メモリ管理ってのは 本来アクセスしちゃいけないアドレスに簡単にアクセスできちゃう(ポインタ)ってことでは? また、スタックチェックはWindowsが行うわけじゃなくて スタックチェックライブラリがリンクされるかどうかなので コンパイルオプションしだい。 それに例外はC言語じゃなくてC++言語だし。
700 :
698 :2005/09/19(月) 07:47:26
メモリ管理というのは、mallocとかnewとかで割り当てられるメモリの管理ね。 GCしたところで、 > 本来アクセスしちゃいけないアドレスに簡単にアクセスできちゃう ことは防げないけどね。 それにC/C++でもGCはできる。 言語が強制するのではなく、ユーザが自由にやればいいんだよ。 スタックオーバーフローはOSが行ってるよ。 スタックオーバーフローすると、そういう例外が出るから。 > スタックチェックライブラリがリンクされるかどうかなので という話は、スタックオーバーフローではなくて、バッファオーバーランでしょ? WindowsでOSが出す例外は、正式名称は「構造化例外処理」というもので、 CやC++などの言語とは関係なく、OSの機能として備わっているものですよ。
俺はどっちかというと int *p ; ではなく int* p ; と考えるといいと思うんだが・・・・
だからさ、なんで型宣言を、部分で見ようとするのかな? ファンクション型宣言とか使えない奴らなのかな?
関数ポインタもtypedefします。
>>701 おれは int *p と考えないと脳がパンクしちゃうので。
int a,*b とあるとき、 aと*bは同じ意味だし。
でも、(int*)&a と b が同じという考えも納得はする。
となると、まあ宗教だなこりゃ。
>>704 あんたが正しい
typedef のときは int* 型だし、
通常宣言時は int *i; だし、
cast時は (int*) というのが正しい。
これは演算の優先順位とかと同じ考えかただ。
キャストはなぜか (int *) で統一してますが何か
>>706 ああ、そうそう。
スペース開けたほうが見やすくていいんだった。
typedefもcastもポインタ型なのがはっきりしてるから。
ただ、通常宣言時だけ、適用対象が特定変数だから、
変数に対してつける意味で変数の前につけるんだ。
おまいらがそんなこと言うんで、 俺のソースには int *p;とint* p;が混在しちゃってるじゃないか。
じゃあ、せっかくだからint * p;も入れよう
× cast時は (int*) というのが正しい。 ○ cast時は (int *) というのがみやすくてよい。
◎どうでもいい
文法的に可能な限り、改行せずに書いたら、悲惨なことになるでしょ。 それと同じように、文法的にはどうでもよくても、コーディング上はどうでもよくないの!
たかがスペース1個に何をガタガタ言ってるんだ? 改行と違って、キャスト式の内部の空白1個の有無で、 極度に読みにくくなるわけでもないだろ? その程度ならどうでもいいよ。
ただ、プロジェクト内では統一したいよな オレコーディング規約でもなんでもいいから統一すべし 検索するときに (int *)と(int*)とが混在してると たったコレだけのことに性器表現を使う羽目になり おにんにんがおっきおっきしちゃうのぉおお
>>715 インチキ臭い理由付けだな。
int*で検索するよりも、変数・関数名で検索しないか?
そこで_castで検索できるC++キャストですよ。
>>715 ”(int”とか”*)”で検索すればいいやん。
>極度に読みにくくなるわけでもないだろ?
読みにくいよ
スペースの有無で探せば眺めるだけでいいから
作業効率がぜんぜん違う。
>>718 それじゃ他のキャストや関数と間違えちゃうでしょ
正規表現を使う面倒を避けるためだけに 規約を追加するというのは正しいとは思えない
括弧がネストしたり、式が長かったりしたら(int*)とスペースを入れないときもあるし、 間違って(int *)とスペース2つ入ってる場合も考えられるし、 検索するなら正規表現でやっぱやるだろ。 手間なんて殆ど変わらんじゃんか。
ちょっと眺めてみて、 俺的にはこのスレあぼ〜ん対象でした さよなら
世界が平和になるおまじない #define ptr(type) type* /* examples */ ptr(int) pointerToInt; int justInt;
悪魔だな。 代わりに魂を差し出せ、と?
悪くない。
defineがそれじゃちとまずいだろ。 自分の意図しない動作が起きたって知らないぞ。
ptr<int> の方が良いのかねぇ
defineってスペースは考慮してくれるのか?
基本的にスペースは無視だろ?
define って、単なる文字列置換でしょ?
#define USE_POINTR(type) typedef type *ptr_ ## type ## _t; #define USE_ARRAY(type, size) typedef type array_ ## type ## _t[size]; #define USE_FUNCTION(type, name, ...) typedef type func_ ## type ## _ ## name ## _t(__VA_ARGS__); USE_FUNCTION(void, sig, int); USE_POINTER(func_void_sig_t); ptr_func_void_sig_t signal(int, ptr_func_void_sig_t);
732 :
デフォルトの名無しさん :2005/09/25(日) 11:39:12
このスレ面白すぎ。
C言語の場合 int*f; int* f; int *f; は、おなじ?
アセンブラのソースに落して比較すりゃいーじゃん。 つか、それくらいやれ。
わざわざんなことするかバカ
>>734 文句言うのに2行
答えるのは1行
どちらが楽か自分で考えれよ
>>737 安易に教えて君プログラマを増殖させると実生活で困る局面が多いからなぁ。
どっちが楽かって考えるとねぇ…一行とか二行とかの問題じゃないと思う。
>>733 C及びCライクな文法を持つ大抵の言語は、トークンやシンボル境界のスペースはあってもなくてもOK。
例外としては、テンプレートクラスが入れ子になっている時の閉じ括弧くらいかな。
T1<T2> > // ←これ
スペース入れないとビットシフトになってしまう。
int* a, b; // a, b の型は int int *a, b; // *a, b の型は int
ハァ?
わるい。とりあえず自分が頭悪いということを理解した。
>>740 a++ +b
a+ ++b
a+++b
どれだ?
a/ *b とかも
なんて参考にならないスレだここわ!
いえいえ、とても参考になりますよ
嘘ばっかり言われて参考にはならにー
嘘とわかる時点ですでにそれは嘘ではないんだ。 ほんとうの嘘は、誰にもそれが嘘かどうかなんてわからないんだ。 だから嘘をつかない人がいたとしても、その人が本当に嘘をついていないかは
まるっとお見通しだ!
Cのポインタ周りを設計した香具師、ちょっと出てこい。 俺はこれでプログラマになり損ねて今はフリーター。 狂った人生をどうしてくれる。
>>752 呼んだかね?
私が君の質問に答えよう。
ただし! 1回だけだ。
>>753 彼女ができるようになるにはどうしたらいいの?
>>752 良かったね。
ポインタごときの低いハードルを越えられないようなら、
その先のもっともっと高いハードルの数々は無理でしょう。
早めに軌道修正できて良かったと感謝すべきだろう。
もっと深い事情がありそうだ
>>754 考え方を変えよう、君が彼女になればいい
さあ、今から二丁目に行って来よう
ウホッ
>>758 ウホッ じゃないよ。馬鹿だな。いいか、お釜とゲイはぜんっぜん違うんだよ。
お釜は自分が女性でありたいと願うが、ゲイは男として男が好きなんだよ。
何こいつw
>>760 「何こいつw」 じゃないわよ! あんたまであたしを馬鹿にする気!?
そうやって人を見下すようだからいつまで経っても独り身なのよ!!
僕には愛するミギーがいますから。。。
で? スレタイとは全く違う方向だが??
そもそもどうでもいいスレ
どうりでsage進行・・・
よし、ミギーが彼女なやつは手を挙げろ!
俺はヒダリーヌ派なので…
俺はミギーもヒダリーヌもどっちでも。でも本命はヒダリーヌかな
>>768 あたしの他にもいい人がいたのね
その人どこにいるのよ、呪ってやる
お口の恋人ロッテ
こすり付ける派の彼女は誰ですか?
滝真倉さん
奥地の恋人ロッテ?
いくら体が柔らかいったって自分で咥える気になれるか?
775 :
766 :2005/10/08(土) 05:24:39
よし、
>>774 を体が硬くてできなかったけど試してみようとしたことあるやつは手を挙げろ!
ノシ
サー
778 :
766 :2005/10/08(土) 21:57:09
よ、よし俺以外にも居るな! ノシ
自演乙
乙かれさま
781 :
デフォルトの名無しさん :2005/11/14(月) 06:55:56
int *ptr: int index=0; 略 index++; (ptr+index)=(int *)malloc(sizeof(int)); こういう使い方が出来ないのがめっちゃ不便。 代替策も思いつかんし・・・
>>781 >(ptr+index)=(int *)malloc(sizeof(int));
何がしたいのか意図不明す。。。
ポインタ配列を使うのはダメなのか?
ポインタ配列を意図してるなら、sizeof(int)はNG。 32bit環境では帳尻が合うが、意味がぼやけてる。 64bitではサイズが足りない。
int **ptr = (int**)malloc(sizeof(int*)*length): int index=0; 略 index++; (ptr[index])=(int *)malloc(sizeof(int));
>>785 う〜ん、それだと配列の長さが固定になってしまう・・・
malloc(sizeof(int))の意味がわからん。 int 1個のために一々mallocする理由がわからん。
意図が伝わらないコードは糞コード
>>788 おそらく、ポインタにオフセットをつけ、mallocした領域(変数)を
登録することで可変長配列を実装したいんじゃないかと。
でも、そうするなら mallocした領域(変数)を登録する領域を
可変長にしなければ意味がないんだが。
こういう形で可変長配列を実現してる言語ってあるん?
>>871
791 :
790 :2005/11/14(月) 23:22:51
calloc realloc
おまいらセンス無いからダメなんだよ。
794 :
790 :2005/11/15(火) 00:12:23
>>792 まぁ、普通に考えたらその関数でintの配列として使う領域を確保するよなぁ。
CPUキャッシュやメモリのバースト転送のこと考えたらポインタのポインタで可変長配列、という時点でダメ。 その辺考えたら、普通は、 ・malloc()で多めに確保。 ・ポインタとオフセットで配列のようにアクセス。 足りなくなったら、 1:代替領域確保→元の領域から代替領域へメモリコピー→元の領域を開放。 2:テンポラリファイル書き出し→realloc()でさらに大き目の領域を再確保→テンポラリファイル再読込み 3:複数のメモリ領域にまたがっていても動くようにする(少々面倒だが現実的)
>>795 ああ。マシンは十分早いのでその辺は考えなくていいです。
プロを煽るならもうちっと高度なことを書いてください。
Cにはポインタという型は無いのだが?>1
>CPUキャッシュやメモリのバースト転送のこと考えたらポインタのポインタで可変長配列、という時点でダメ。 でも、スタックにオブジェクトインスタンス作れない言語だったらそうなるわな。 まぁnew[]やらdelete[]やら使ってなさい、ってこった。 deleteに[]を忘れたり、deleteせずにreturnしたり例外に吹っ飛ばされるようなお子様はベクタ&スマポでも使ってなさい。 mallocは10年早い。
C++ で malloc 系使ってたら阿呆だが、それより いつのまに C++ の話になったんだ?
>>800 C++の標準ライブラリはアホなんですね。
標準ライブラリって実装方法まで指定されてんの?
C++でmalloc使ってはいけない理由キボンヌ
>>799 STLのvectorって例外をthrowするよね。
つーことは、例外のないCでは困ったことに。
freeを使うなって言うのはデストラクタが呼ばれないから 大きなお世話だよね
>>803 mallocを使ってはいけないというわけではなかったと思う。
ただ、new演算子を使うほうがよりスマート(サイズを与えるのが楽だとか、
戻ってくるポインタをキャストしなくていいとか、確保に失敗したときは
例外を投げてくれるとか)だからってことだったような気がする。
重要なこと忘れてた。 new演算子には領域確保を抽象化(?)して プリミティブ型とオブジェクト型を同列に扱うというのがあったな。 0で埋められたインスタンスと同じサイズの領域ってのは 必ずしもインスタンスにはならんわけで。 これがmallocではなくnewが推奨される理由だと思うんだが。 #これ以上詳しいことは知らんので間違ってたら笑い飛ばしてくれ。
C++でnewが推奨されるのは何よりも804の逆でコンストラクタが呼ばれるから。
クラスのオブジェクトに対してmalloc/freeする馬鹿はいないでしょ。
>>808 それはおまえが無知なだけ
stlのソース見たらわかると思うが
listとかはあらかじめmallocで数個分のオブジェクトの領域を確保しといて
そこにplacement newでオブジェクトを配置してる
C++でnewが推奨されるのは、それを無くすと 誰も C++ をオブジェクト指向だと認めてくれなくなるから。
>>809 それをクラスオブジェクトをmallocすると称するのかね?君は?
STLがなにをしているのかとSTL利用者がなにをしようとしているのかでは 100万光年からの開きがあるよ
>>809 STLの実装によって違うのではないかと。
vector::reserveしたら、コンストラクタがゴリゴリっと呼ばれてワロタこともある。
用途、環境に合わせて適切なデータ構造やアルゴリズムを選択できない御子様は、 外見だけ華やかな流行の技術でもつまみ食いしてなさいってこった。
>>809 阿呆ですか?
内部の話始めたら、そもそも new が malloc(ry
糞みたいなやり取りだな
>>816 当然だが、内部でmalloc呼んでないnewの実装もあるよ。
newがオーバーロード出来るのを忘れてる人は結構いると見た。
巨new
逆にmallocの実装に::operator newを使ってはならないと読んだ記憶がある。
mallocはヒープ領域に newはフリーストアに割り当てると 山本信雄のVisual C++ 2巻に書いてあったけど なんのこっちゃ分からんしどうやって実装すればいいか検討つきません。
VC++じゃ、ヒープ=フリーストアじゃなかったっけ?
そうだとしても、むしろ間違ってはいないだろう
VC++のmallocはソースを読めばわかるけど、ちょっとややこしいよ。
でも結局はHeapAllocを呼んでいるだけだよ。
まあ、C++になってヒープがフリーストアという名前に変わったと理解してても 大抵の処理系では問題ないはず。
heap ━━ n. (うず高い)山, 積み重ね; 〔話〕 (pl.) たくさん, うんと (This is 〜s better.); 〔話〕 ポンコツ車; 【コンピュータ】ヒープ ((確保したメモリ領域)). all of a heap 〔話〕 どさり[ぐったり]と(倒れる); すっかり; 出し抜けに. heaps of 〔話〕 たくさんの…. in a heap 山積みに[の], 積み重なって[た]; どさり[ぐったり]と(倒れる). ━━ v. 積み重ねる ((up)); 山積み[山盛り]にする[なる]; 大量に集める; たくさん与える ((with)); (賛辞・侮辱などを)浴びせかける ((on)). heaped ━━ a. 山盛りの (a 〜ed spoonful スプーン山盛り一杯); 積み重なった ((with)). heap sort 【コンピュータ】ヒープ・ソート. たしかに「ヒープ」よりはわかりやすい言葉かもしれない。
ヒープ構造とは限らなくなった、ってことじゃないか? 呼び方が変ったのは。
ヒープ構造ってどんなの? 俺は、bssセクションとスタックの間の空間ってだけだと思ってたよ。
その空間の割り当てをどうやって管理するのか、という話よ>ヒープ構造
そんなガキのいちゃもんみたいなこと言ってないで、 どういった構造をしてるのか説明するのが大人の対応ですぞ。
DOSの場合のヒープはUCB
win9xではローカルヒープとグローバルヒープに分かれてた。
昔の名残よのお、、、
いまはおなにー
ヒープはプロセスがその都度OSにお伺いをたてて、許可されたら確保されて 手渡されるメモリ領域。土地登記のような厳格な管理下に置かれる。 スタックは予め手渡されているローカルでLIFOなメモリ領域。スタックオーバー はプロセスの自己責任。再帰処理ではよく注意して想定内で使うしかない。
誰かスタックの話をしてました? フリーストアってみんな言ってるように見受けられます。
OS管理ではないヒープもあるがな。 OSからは大きなサイズで割り当ててもらって、 Cランタイムライブラリ側で管理するのも手ですよ。 ただそうすると、メモリが無駄になるので・・・。
ちょっと待って、今
>>841 が
>OSからは大きなサイズで割り当ててもらって、
>Cランタイムライブラリ側で管理するのも手ですよ。
ものすごい当たり前の事を言った!
大体のライブラリはそういう実装になってるよな。
mallocなんてその代表格じゃないか?
ただ闇雲に否定したいだけ?それとも無知?
学生さん
VC6のCランタイムのソースでは、OSに管理させてるな。 といってもWindowsの場合、 Win32APIの呼び出しはシステムコールとは違う。 さらにランタイムライブラリが一枚噛んでいるいるようなもので、 HeapAllocを呼んでも、DLLの中で処理されて戻ってくることもある。
HeapAllocはメモリブロック単位で管理してるんじゃなかったかな。
*記号の流用が許せない あるときは乗算記号、またあるときはポインタ、またあるときはコメントの一味 しかしてその実体は
参照を忘れてるぞ。 *hoge = xxx みたいなの。
852 :
1 :2005/12/19(月) 22:08:41
このスレが、こんなに伸びるとは思わなかった
そりゃそうさ。 普通はポインタを理解しよう、という方向になるのに このスレはストレートに「おかしい」だからな。 挫折者・落伍者にはオアシスのようなもんさ。
実際のところ、ポインタに躓いている人を観察するとさ、 クソッタレなC言語入門書に書かれているオナニーな用法で、躓いてる。 たとえば、ポインタのポインタ。 型という概念とtypedefの使い方を教えれば、ポインタのポインタは必要なくなる。
もっと革新的な説明の仕方をしてくれてる入門書はないか。 どれもこれもタンスの絵ぱっかでゲロが出そうだ。
タンスの絵とか本の目次とかで理解できなきゃ、 頭を取り替えない限り理解できない
>>850 C++ なんてもっと酷い事になってるからな。
余計な思想まで継承しなくていいっつの。
>>855 メモリにはタンスの引き出しみたいな仕切りは存在しないからなぁ。
カセットテープの場所を指差すもの、というイメージなのだけど、
今の若い人はカセットテープ使わないからわからないか。
方眼紙の升目に数字を書き込んで・・・・というのでも分かりにくいか? そもそも、アセンブラも未経験、コンピューターの基礎知識、動作原理の知識も無し、 パズルや数学が苦手(理論的思考を不得手とする)なプログラマが多数派になりかねない現状では無理ないかも。
しかもポインタレス言語マンセーだしな
>>857 Cをまるごと受け継ぐというのがC++の最重要な方針だったわけで。
だからこそC++は成功したんだとStroustrupはD&Eにはっきりと書いている。
それが成功したってことはプログラマがいかに保守的かってことか...
て言うか、人は大体保守的だよ。
C との互換性が高ければいい、というものでもないらしい。 つ[Objective-C]
>>857 新しいC++の規格には型の新しい修飾( 右辺値参照だっけ? )
として && が採用されようとしてるぞ。
また記号の流用かよ orz aaa<bbb<ccc>> や a = b/*c; で全く懲りてないんだな・・・。
$は未使用だよね。 なんで$を使うのを避けるのかな。
$(笑)
'$'の他にも'@'とか'`'とか。 それぞれダラーや単価記号や逆向きクォートとは限らないので使われないのか? その割りには'{', '|', '}'もトライグラフで置き換えられるわけだから使ってもいいだろうに。
870 :
デフォルトの名無しさん :2006/02/05(日) 15:40:24
>>867 $はバックスラッシュでしょ
\と同じコード。
通貨単位だから。
でも、両方出るなあ。
@は単価だし
871 :
デフォルトの名無しさん :2006/02/05(日) 15:55:40
C++で好きなように演算子つくれ。 ************************** 終了 **************************
>>870 落ち着いて話そう。
まあ、クソスレだしいいか。
&の使いまわしも気に食わないよな a &= &a && a & &a; とかどうなんのよってのな
&ヽ(`Д´)ノ&
876 :
870 :2006/02/05(日) 20:42:56
バイナリからデータサイズ毎の先頭アドレスを取り出して扱うってのは PCの実際の動作に近くていいと思うんだが。 大体、ポインタがなかったら多重リストの実装とかどうするんだ。
記号の多重使用が気に食わない、文法が気に入らない、ポインタ(というか、コンピューターの動作原理)が理解できない。 そういう香具師が見かけポインタの無い高級言語を持ち上げてCを貶めようとしているかのよう。 アスキーで昔(エンターブレインになる前)出てた256倍シリーズのC言語本にはC始める前にアセンブラとPascal習得しろとか書かれてる。
俺、アセンブリ→PL/M→C の順にやったんだが >記号の多重使用が気に食わない、文法が気に入らない これは激しくオモタ。流石に慣れたが。
>>878 多重起用がうざいってのも
半分はネタで言ってるだけだがな
でももう半分はマジ
そういや、某マシンの某OS上でしか動作しない言語にゃあ、そのマシン特製キーボードにしかない記号を使って記述する物があったな・・・ポインタの記号だったかなぁ・・・
自然言語に比べたらはるかにマシ
>>881 言語専用文字と言えば APL を思い出す。
884 :
デフォルトの名無しさん :2006/02/15(水) 22:42:26
885 :
デフォルトの名無しさん :2006/02/16(木) 01:23:43
int* p; って解釈するんじゃなかった? int* を typedef で別名にすれば解りやすい。
int * p; *p この両者が似ているのが混乱の元。 どっちも変数の前に*をつけてるだけなのに 一方はポインタ変数であることを意味し、他方はポインタの中身を意味する。 感覚的には変
>>886 おいおい、C言語の基礎からやり直せw
その形式は別にポインタだけじゃないだろ。
そのまんまの記述で型を指定するってだけで・・・
中身はint型になるようなポインタ変数を定義・・・って考えれば何の矛盾も有馬線。
889 :
デフォルトの名無しさん :2006/02/16(木) 06:05:29
>>886 int *p;と書いて「*pがint型」になると読めばよいというのがお約束。
891 :
デフォルトの名無しさん :2006/02/16(木) 11:11:05
>>887 おいおい、宣言子と演算子が同じでキモイって話だろ
C++/CLIの ^ 演算子の方がずっとキモイと思うんだが・・・・
BYTE buf[64]; for(int i = 0; i < 16; i++) *(int *)&buf[i * 4] = i;
>>893 これやって、ライン1日止めたなぁ・・・
895 :
デフォルトの名無しさん :2006/02/17(金) 03:55:03
int が16ビットな環境だったとか?
サイズの決め打ちはするな、きちんとsizeofしろって耳にタコが出来るほどいわれたな。
>>886 宣言は宣言であって宣言以外の何者でもない。
>>895 昔のコンパイラはintが16ビットなのが多かった。
そして今後は64ビットのが出てくるかも知れない。
int16_tみたいなのって、gcc以外は使えないんだっけ。
あほの子のVCが使えないだけ。
>>900 たとえば
1. C++で<boost/cstdint.h>
2. 自分で自分の処理系に沿った内容の<stdint.h>を作れる。
>>902 boostにもあるのか。
ありがとう。
<boost/cstdint.hpp>だな。
>>886-891 C++ では int* p とするのは, やっぱり int *p とするのがキモイからなのかなぁ.
C++ やり始めて, どちらもかみ分けて読めるようになってきたけど,
C から始めた者からすると int* p の方が少しキモイ.
だから, 参照とかを覚えるときも int &p = a; とする方が, 覚えやすかった.
俺はC++をやり始めたときにはint *p; int& r;だったけど、 いつのまにかキャスト演算子の時にはint*を使うようになり、 最近変数・宣言でもint* p;になってきた。
っていうか、全部変だよC言語
30年も前に作られた言語に文句言ってもしょうがないじゃないか。
つーか何もおかしくない
日本語の方が遥かに複雑怪奇
気に入らないなら気に入るものを自分で作ればいい。
ていうか、いまだにプロトタイプ宣言の意義がさっぱり理解できません。 どう考えても冗長以外の何でもねえだろあんなもん。
>>912 コンパイラが全部面倒見るべき? そういや Delphi とかはそうだったかな?
>>912 コンパイラがソースコードを上から下へ1回読むだけでコンパイルできるように。
>>914 なんで人間様がコンパイラに仕えなきゃなんねえんだよ。
……と普通は思うでしょ。
Cの文化ってこういう倒錯が結構みられるよね。
たとえば最適化なんかに関しても。
プログラマに向いてないな
>>917 君がねw
現にたとえば最適化のような猿仕事はコンパイラがやるべきであって
可読性を犠牲にするようなアクロバチックな記述はすべきでないって風潮になってるでしょ。
>>916 Cができたのは30年以上も昔のことだ。
そのときのコンピュータの性能を考えれば仕方がない。
ちなみに俺はまだ生まれていない。
>>918 人間が最適化するのはそれを超えたところが存在するから
でもプロトタイプって昔はなかったんだよな。 ANSI Cの時点で追加されたんだよ確か。 80年代の終わりごろならパソコンの性能でもプロトタイプなんてなしで コンパイルできるような仕様が十分現実的だと思うんだけど。
プロトタイプ宣言するのが面倒くさかったら、 プロトタイプ宣言を自動生成するようにすりゃいいじゃん。 俺は面倒くさかったから、 #define AUTOPROTOFUNCTION しておいて、 AUTOPROTOFUNCTION void FooBar(void) { /*関数の中身*/ } のように書いておき、 AUTOPROTOFUNCTIONと書いてある行を抽出してヘッダファイルを生成してたよ。 でもさ、C++になるとクラスの宣言と実体はファイルを分けるわけで・・・。
>>913 残念ながら、Delphiにもそんな機能は無い。
interface部又はforward付けて宣言しなくちゃダメ。
まあ自動生成なんかさせてたら プロトタイプで型チェックさせるっていう もともとの目的は無意味になるんですがね。
>>924 お前はわかってない。
Cにプロトタイプ宣言が導入される前の、あの悲惨な状況を。
自動生成つっても、関数の実装から生成するんだから、
人間が書いたプロトタイプ宣言と一致するでしょ。
ヘッダにプロトタイプ宣言を書かないなら ライブラリとか、WindowsだったらDLLにも プロトタイプ情報を含めないとな。 それで実行時に動的チェック、と。 んなアホなことやってられる訳ねーだろ。 自動生成とか言ってる自分本位の馬鹿は死んでくれよ。
プロトタイプを宣言しないってことは、 あるソースをコンパイルしているときに関数呼び出しをみつけたら、 他の全ソースからその関数の定義を見つけだすって事だよね。 ソースファイルが数個程度ならともかく 数千、数万もあるようなプロジェクトではどうなるんだろう?w
どうもならんでしょ。 だってアセンブラには最初からプロトタイプなんてないよ。 もちろんアセンブラにはシグネチャって概念はないけどね。 今のドトネトはもちろんだが、それどころかパスカルにもそんなもんはねえ。 つーかコンパイラじゃなくてリンカの仕事じゃないのそれ。
だな、呼び出し側できっちり型指定すればすむこと。 昔はそうしていたんだし。
>>922 そんなことしなくても cproto っていうコマンドで作れるよ。
少なくとも Linux では動いた。他のOSでは知らないがUNIX系OSなら
動くんじゃないかな。(Windowsは知らない。でも最悪Cygwin使えば
動きそうだな)。
>>927 オブジェクトファイルやライブラリに型情報を含めて持たせて
そこで判定すればいいんじゃないか? あるいはオブジェクト
ファイルとソースの間にもう一つ中間的なファイルを作って
そこに情報を持つか。一度コンパイルすると自動でそれが
作られる。で、まとめてライブラリに付属させる。
まあでも無理にC言語でやる必要はないな。そういう言語
作った方がいいんじゃないかな。
ていうか Java 使ったらどうか?
>>926 >それで実行時に動的チェック、と。
なんでそうなる。
>んなアホなことやってられる訳ねーだろ。
阿呆はお前だ。
>>927 リンカになるべく手を入れなくて済むよう、多くの C++ 実装では
関数名の mangle をやっている。同様にすればよい。
何にせよコンパイラが関数の型チェックするのは無理があるでしょ。
>>926 > ライブラリとか、WindowsだったらDLLにも
あほですか。
そういうものはプロトタイプ宣言したヘッダファイル必須だろうが。
ここで話をしているのは、自分で作った関数について、
プロトタイプ宣言をいちいち書かないといけないのが面倒だから、
自動生成にしたらよい、っていう話でしょうが。
外部ソースへの参照が有るか無いかだけじゃん。 有る時に規模の小さい日曜プログラムならヘッダー要らないように出来ないかって話だろ?
ないある
プロトタイプ宣言の必要性が分からない馬鹿はプロのプログラマにはなれない
「必要性」ではなくて「重要性」でそ
Java にはそんなものはないわけだが。
Javaは馬鹿のプログラマが使う言語と…。
だから「全部変だよC言語」。 頭の悪い奴は「頭が悪い」それゆえに 自分が頭が悪いと思われることを恐れ「裸の王様」をマンセーする。 で、人間てのは恐ろしいものでそのうち防衛機制が作動しだして なんだか本当に裸の王様がステキに見えて来る、とw
えっ? 自己分析?
Cと宣言の文法だけを(好きな様に)変えた言語を設計して それでその言語のコンパイラを書いてみればCの合理性が分かる かも知れない
Cより使いやすい言語が出来るかもしれんな。
そうそう。おかしいと思うならおかしくないものを使えばいい。 なければ作れ。
947 :
デフォルトの名無しさん :2006/02/23(木) 21:32:06
個人的には記号の使いまわしが気に入らないので 新しい言語を開発するにあたり解決すべきポイントは 新しい文字・記号を生み出すということです。 つまり、新しい文字が出来れば全ての問題は解決です。
>>947 それは中国人の発想だな。
そういう考えの結果が積もり積もって、
現在の膨大な量の漢字が生まれてしまった訳だが・・・
結局、歴史的には、記号の数が少ないアルファベット文化が
世界を制してしまった点については、どう思う?
世の中アルファベットぐらいの数の文字しか操れない低脳の方が多いからな。
>そういう考えの結果が積もり積もって、 >現在の膨大な量の漢字が生まれてしまった訳だが・・・ 別にそれ自体は悪いことじゃないだろ。 英語だって知らない単語を見せられても意味なんてわかんねぇし。 >結局、歴史的には、記号の数が少ないアルファベット文化が >世界を制してしまった点については、どう思う? 君の言う「世界を制した」というのが、いったい何を持ってして 「世界を制した」と言ってるのか全然わからないんで、まずは そこんとこを説明してくれまいか? あと君はあの悪名高き trigraph についてはどう思う? 記号の数が少ないことによって起きた悲劇なわけだが。
>>948 そういうの論理の飛躍っていうんじゃない?
頭の悪い発想だよw
947じゃなくても普通のプログラマならASCIIの文字セットに不満持ったことがあるでしょ。
たとえば些細なことだけどギリシャ文字の接頭語が使えないから
苦し紛れにuSecとかさ。
>>950 >別にそれ自体は悪いことじゃないだろ。
本当に悪くなかったらば、中国自身が使用する漢字の量を減らそう、
なんて考えたりはしなかった思うけど?
>そこんとこを説明してくれまいか?
一番分かり易いのが、科学全般の発展具合。
漏れは別に「中国の科学と文明」の信奉者ではないが、
それでも科学の黎明期における中国の役割は非常に大きかったと思う。
その大きさと、その後に続く現在の発展具合を見る限り、
漏れでなくとも、誰だって「ナンデ、ソウナルノ?」って気になるだろ?
でも、こんなのは当たり前と言えば、当たり前。
長い間、ご当地で生まれた秀才は皆が皆、科挙の為にタコツボに入って、
数十万・数百万の漢字を必死に覚え込んでいたんだからな。
彼らが生産的な方向に脳みそを使い、かつ円滑な交流がなされていれば、
どんな素晴らしい結果が生まれたのだろうと考えると
悔やんでも悔やみきれない。
>あと君はあの悪名高き trigraph についてはどう思う?
>記号の数が少ないことによって起きた悲劇なわけだが。
スマソ。トライグラフが存在していた事によって起こった
"悲劇"って一体何?
>>952 漢字を覚えるのは簡単。
英単語を覚えるのといっしょで 意味の組み合わせと法則を
それなりに理解してれば、覚えるべきは例外のみで済む。
>>953 ならば、その秘訣とやらを「やねうらお」大先生あたりにでも
教えてやれ。
漢字検定1級を取るのが悲願らしいから。
泣いてよろこぶぞ。
表音文字と表意文字を題材にした比較文化論のスレはここですか?
ハングル文字でも学んどけ 楽だから
Delphiの自動プロトタイプ宣言とはコード補完の事では?
>>948 漢字使ってる人口がどれだけいるか知ってるのか?
世界人口の1/3は漢字を使ってるぞ。
>>952 いや、だからさぁ、なにがどう世界を制したのよ?
あと、おまえ、trigraph を見てなんとも思わんの?
trigraph を知らないだけ?
>>958 >世界人口の1/3は漢字を使ってるぞ。
世界のプログラマの人口比率でも、
1/3 位は COBOL を使っているだろうな。
>>959 >いや、だからさぁ、なにがどう世界を制したのよ?
>>952 を読んでないのか、読んでも理解できなかったのか、
最初から理解したくないのか、俺に知るすべは無いが、
これ以上俺に
>>959 に納得させる能力はない。
俺の能力不足を許してくれ。
>あと、おまえ、trigraph を見てなんとも思わんの?
いや、「思う」とか「思わない」の話じゃなくて、
渡来グラフのために、現場で "悲劇" が起こっているんだろ?
>1/3 位は COBOL を使っているだろうな。 おれの分野だとひとりも見たことが無い
962 :
デフォルトの名無しさん :2006/02/24(金) 11:27:56
馬鹿だなお前らは プロトタイプ宣言なんてやめて、プログラムを宣言部と実現部に分ければいいんだよ という事でAdaを使いなさい
もうわずらわしいから機械語使おうぜ
>>あと君はあの悪名高き trigraph についてはどう思う? >>記号の数が少ないことによって起きた悲劇なわけだが。 > >スマソ。トライグラフが存在していた事によって起こった >"悲劇"って一体何? 日本語読めないバカハケーン
>>964 いや結局「悲劇」とやらの内容を一切説明してないんだが。
ま、どうせ「意図せず別の文字に置き換えられて悩んだ」とかだろうが
そりゃ無知だから悩むんであって、悲劇でもなんでもない。
まだわからんのか。小学校の国語からやり直せ
つまり trigraphの発明→(なんらかの)悲劇の発生 じゃなくて 記号の数がすくない→「trigraphの発明」という悲劇 ってことだろ
で、それの何処が悲劇?
非常にわかりやすくていいなw
>>965 無知なのはお前。m9(^д^) プッ
973 :
デフォルトの名無しさん :2006/03/15(水) 00:01:18
結論としては「宣言の仕様はおかしいが、概念がわからない奴はバカ」ってことでよろしいか
) _ ,, -ー=- 、 ヽ 異議なし!! ゝ、ニ 二 _ ミミV, ) マ二 ニ、 r' ..,,_ ヽソ, `v'⌒ヽ/⌒ヽ/ ,. ‐- .. _ `ヽ、 { a`' tij` _! / __ `` ー- 、 |ノゝi ,_〈 , ィ/ ゝヽ ̄ヽ ー- ' / t -‐ ,'" _ / { {ヽ、_ ヽ' ノ_,.〉 /! `>、 _/_ -ァー- 、_ ... -‐ ' ヽヽ、 `>、..ノ=┘ /j >-‐ ' ´/ / / / _ノ \ `ー '! , -‐ 7´/{⌒| / _/ j >‐' / / //| 〉‐f/ \' ! , ' ´ / ,' > .|/ レ ゚ノ | ,.. -‐ '" / { ヽ | 〉 /__ t ,. -‐ ' ´ | ヽ| / / ' ` ヽ、 / | `!// /
975 :
デフォルトの名無しさん :2006/03/15(水) 02:42:28
C言語が悲劇的だったのはその統一されていない仕様ゆえに IDEによる自動化の恩恵をあまり受けられなかったこと それゆえに生産性ではJavaやC#の後塵を拝することになる
976 :
デフォルトの名無しさん :2006/03/15(水) 08:53:11
生産性ではな。 ここ一番の最強プログラムはほぼ例外なくC/C++
977 :
デフォルトの名無しさん :2006/03/15(水) 12:20:29
最強とか言ってる時点で厨確定
C#が、 実行に必要なすべてをスタティックリンクできて、 EXEファイルが10MBくらいに収まるなら、 大歓迎なんだけどなぁ。
>>975 TurboC とかあったのだが。
PCの場合、スペックが高速大容量化したからCにする
必要性がなくなっただけなんじゃないか? 小さくて
効率のいい実行ファイルを作る必要はないもんな。
それだけでなくPCの場合ユーザの要求が高まってCだけで
作るのは辛い状態になった。
TextSS のWindowsXP(Professional)64bit化おながいします もしくは64bitにネイティブ対応したテキスト置換ソフトありますか?
ここは劣化したfjでつね
>>983 どちらも合わないと思う。
おかしいのは文法であって、ポインタそのものの概念は
おおむね問題ないと思うがどうか。
意味が一意に決まってるし、文法上おかしいとか思わん
文法も概念もおかしいと思わん
文法の問題じゃなくて、表記法が綺麗じゃないってだけなんだよな
宣言の構文もおかしいと思わんが?
char (*(*p())[])(); こんなに複雑な宣言ができるのだよ
関数ポインタを返す関数って、typedefを使わない場合のプロトタイプ宣言はどのようになりますか?
992 :
デフォルトの名無しさん :2006/03/26(日) 02:33:30
きみょうな字句解析研究者のオナニーということでよろしいか。バッカス表記も
>>990 そういや複雑なポインタの宣言を自動生成してくれるツールとかあったな。
**
パズルみたいなのはダメでしょう。
1000
勝手に他の言語の概念持ち込む方がおかしい。
よく続きました。 これで終了します。 この話題はもはやこれ以上続きません。
1001 :
1001 :
Over 1000 Thread このスレッドは1000を超えました。 もう書けないので、新しいスレッドを立ててくださいです。。。