C言語のポインタの文法はおかしい

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の値の代入

のほうが、すっきりすると思うのだけど。

終了

>>1-2
根本的に誤解

根源的に無能

http://YahooBB219180178006.bbtec.net/
ｗｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗｗｗｗっうぇおｋｗｗｗ
っ
ｗｗｗおｋｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗおｋｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

&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の参照である．素人の言葉で説明すると，参照とは芸名みたいなもので, 名前は違うけれど，名前が指している人は同じ人ということである．

おっと間違い

http://ntgnma054253.gnma.nt.ftth.ppp.infoweb.ne.jp/

うはっｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗっｗ
ｗおｋｗｗｗ
うはっｗｗｗ
ｗｗｗｗｗｗうはっｗｗｗ

ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ

アドレス演算とかどうすんのさ

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アドレスにマーキングしても、だめだよ

　　　　　　　　　　　　　　　　　　　　　　　　　　　　■■■■ スレ終焉 ■■■■

元々アセンブラで一般的なレジスタによるアドレッシングの方法がポインタの概念だよ。
だから、そういう観点からいうと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++

みたいな。

>inc esi ;m++
>inc edi ;n++

??
add esi,4 ; sizeof int
add edi,4

既存の言語の仕様が気に食わなければ、自分で言語を作れ！

・・・って、perlの作者の人が言ってなかったか？

>>20
まったくそういうことだな。
今の政治が気に食わないなら自分が総理大臣になれっていう
捨て台詞を吐く友人がむかつく。

>>15
S(p) = S(n) ; // pのアドレスをnのアドレスで上書き
配列をポインタみたく扱うようなもの。
pがリファレンスじゃなかったら、メモリー回収できなくなるでしょ。

うん、最初っから判ってる。
変な拘束ゲーム始めた >>1は
気付かなかったみたいだけどｗ

/** 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)

>>28
職業的プログラマーの俺に言わせれば、
動けば良いのだよ、なんであっても・・・

つーか間違ってないし

コンパイル後はスタートアップルーチンからのmain()の呼び出し方法が変わるだけ

>>28
どうでもいい。
俺は逆に、コマンドラインパラメータを使わなかったり、戻り値チェックしないなら、
void main( void )
で明示してる（していた）。

>>1
答え出したぞ。早くどっちがいいか確認しろ

>>28
初心者はそう書きたがるんだけど、
必要ないものは省略するのがCの慣習なのだよ。

誰もそんなとこ気にしねぇ〜よ。
Cのスタートアップルーチンは、
単に _mainラベルを C言語呼び出し規約で呼び出すだけだからな。

C++と違って、なんでもいいんだよ。
残念

void 姪(void)

リンカ/ローダは _main識別子を捜すから、
C言語上は main 識別子を必ず使えよｱﾌｫ。

マクロ定義してからヤレ。

#define 姪　　　　main
#define 切腹　　 exit

色々釣れたわけだが、

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値の変数へのポインタ値

どうだ、スッキリしたろ。

すまん。括弧が足りなかった。

#define REF(x) (*(x))
#define PTR(x) (&(x))

プリキュアの白いほうって彼氏いるのかな？
当方28歳なんだけど、告ったらふられるかな？？
どう思う？？？

あたってくだけろ

バカじゃねぇの？
>>1-2見て、池沼だと思った。
やっとポインタ覚えたのねｗ

で、プログラムはいつ書けるようになる予定？

じゃ、
>>24が正解、
>>38-39はルール変更で失格


てことで。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝終了＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

>>38
typedefすりゃいいって、そういう問題じゃないだろ。

まあ記号の使いまわしはやめてほしいよな

+と++の違い程度ならまだ許せるけど
a*b の*は掛け算で、 *bとなったらポインタってのは
納得できないと思うよ

そういう仕様 の一言で片付けるには納得しがたい
なぜ*という記号をポインタに選んだのか
その理由を答えろ！カーニハン！

>>38-39
・演算子をマクロに置き換えて、あと
・typedef やっと覚えた、
だけだろう。

＞typedef int *inp_ptr;

＞#define REF(x) (*(x))
ポインタ演算子 '*'　→　マクロ REF(x)

＞#define PTR(x) (&(x))
ポインタ演算子 '&'　→　マクロ PTR(x)

しかし確かに言われてみればそうだよな。
＊である必然性はないわな。
#でも$でも@でもいいだろうし。
なぜあえて掛け算記号と重複させたのか？というのは疑問だ。

http://ntfksm039250.fksm.nt.ftth.ppp.infoweb.ne.jp/
うぇｗｗｗうはっｗｗｗうぇｗｗｗｗｗｗｗｗｗうはっｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗっうぇっｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗ
っっうぇ

っうぇうはっｗｗｗ

C++/CLIでは、マネージポインタの識別子として^を使うわけだが。

XORかよ！

・ビジネス分野で最も普及した関数型言語ＡＰＬの演算子は、
　普通のＫＢとフォントじゃ書けないｗ
・昔の非ＡＳＣＩＩ文字コードを使ったマシンでは、
　演算子にできる文字が極めて少ない
　(現在の半分くらい。どうしても書けない記号はトライコード(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

>>55
_も演算子なのか？

@は、メールアドレスと座標表示用にリザーブ。
~は、AWK　(Aho-Wainberg-Kernighan)で、パターンマッチ用に使用済。
ちゅぅか、'>>'演算子, '<<'演算子の優先順位の設計ミスをなんとかしてほしい。

あと、演算子を議論したい場合は、
最低限「演算子順位文法」とそのパース方法をマスターする
努力をすることｗ

努力だけでいいのかｗ

Turbo C 2.0の時に~は塩山市として使った覚えがある…

~はビット反転。

>>63
今思い出したーよ。
皆がその役目を忘れてる
'~'ﾀﾝ、ｶﾜｲｿ

~　を使わないCプログラマって…

@は演算子として使われているわけじゃないから問題ないよ。

低スキルPGが大はしゃぎだな

>>67-68は>>1-66より低レベルなPG

>>68
自虐的だな

a+=b;
a-=b;
a|=b;
a&=b;
a==b;//これこそ、真の代入ではなかろうか…

デストラクタの~はどんな扱い？

>>70
a=bの結果をaに代入するってことか。

つまりa=bと同じだな。

>71
C言語にデストラクタなどないｗ

typedef struct {
int i ;
} St ;

St s, *sp ;
sp = &s ;

s.i=1 ;
sp->i=2 ;
(*sp).i=3 ;
sp[0].i=4 ;

まぁ、現場ではバグの含有率が一番多いのが、
Ｃ言語で書かれたプログラムだ。

いろいろな意味で、一番タチが悪い。

>>75
Source Please !!

VB だって、COBOL だって負けてはないと思うが。

>>75
そうか、むしろJavaとかの方が多い気がする、適当に書いてもそれなりに動くから、かなりフィックスされないバグが多い気がする。

>>40-41ﾜﾛｽ

オマエラ変な風に考えすぎ。
int a, *p, **pp;
int f();
これで　a も *p も **pp も f() もみんな int型。
シンプルだろ。

int *p; は p が intポインタ型という意味じゃなくて *p が　int型と読むんだよ。
だから、
int* p; なんてキモい表記はするなよ。

C++はﾀﾞﾒでC言語しか語れないｷﾓｲ方なんですね

(*printf)("これだけはキモイ");

(*0)[a]

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番地にアクセスできなくなるから、有り得ない。

>>90
規格読んだけど見あたらない。

古い資料だけどこういう主張もある。
ttp://www.kouno.jp/home/c_faq/c5.html#16

>>92
でもおかしいよね
アドレス0にアクセスする方法が無いのが根拠だとしたら
特別なビットパターンであらわされるアドレスにアクセスする方法も無いよね

>>93
何の話だ？ 藪から棒に。

ああ、そういうことか。
「特別なビットパターンであらわされるアドレス」は、普通はもともと(仮想)メモリの外にある。
空ポインタにアドレス0を割り当ててる場合でも事情は同じ。

>>86
stddef.hに定義されているoffsetofマクロも>>84と
同じじゃん。
貴方の主張が正しいなら

#define offsetof(s,m) (size_t)&(((s *)0)->m) - (size_t)&((s *)0)

こんな感じにしなきゃいけないと思うが。
本来の意味からすれば相対的な位置を知りたいんだから
自分はこっちが正しい気がする。

まぁ、あれだ。
ポインタ使わずに済むなら、使わない方が良い、ってことだ。
バグのもとだし、後から見て分かり難いプログラムになるからな。

キチガイみたいにポインタのポインタのポインタのポインタとか
使って書かれてるプログラムを見せて、自慢げに講釈たれてる
自称スーパープログラマーが昔会社にいたなぁ・・・

( д )　ﾟ　ﾟ

やね○らおのことか

うん、ポインタは使わないほうがいい。再帰でなければmain関数以外なくなって良い。

>キチガイみたいにポインタのポインタのポインタのポインタとか
>使って書かれてるプログラムを見せて、自慢げに講釈たれてる
>自称スーパープログラマーが昔会社にいたなぁ・・・

俺の最高記録は * ４つだが、
* ５つ以上を使った事のある奴
（もちろん意味のあるコードで）
っている？

>>101
構造体も一種のポインタと考えて良いなら、5個まで

int*********i;

>>91
じゃぁどうやって0番地にアクセスするの。

そもそも、ポインタの値 = アドレスとは限らないよね。
メモリの特定のアドレスへのハンドルだと思ったほうがいいのかな。


ポインタのポインタって無意識のうちに使わない?

a->b->c->d->e
なんていうのも、そうなんだしさ。

>>104
＞ じゃぁどうやって0番地にアクセスするの。
Cから直接アクセスできればそれを使えばいいし、できなければアセンブラでも使えばいい。
アドレス指定でアクセスするという行為自体が環境に強く依存するんだから、
移植性は気にする必要はないだろう。

>>88
C のソース上、ポインタとして定数「0」が記述された場合、
それは NULL ポインタとして判断される。

NULL ポインタ値の実装値が、
All 0 のビットパターンであるかどうかは環境依存。

ポインタのポインタのポインタ・・・みたいなのは、とにかくtypedefして使うのが他の人に対する礼儀。

LispでもCでも、明示的なデータ構造なり型を定義せず書くのは、
デッサン画のようなもの

でもさ、typedefはなるべく使いたくないわけよ
あれは型を隠蔽してしまうから、もちろんそのために使うんだけど
たとえば time_t
こう書かれちゃうと、一瞬「これって比較していいんだっけ？」と
躊躇してしまうよ。結局一度はtypedefの定義元を必ず参照する。
ポインタとは関係ない話だけど

＞でもさ、typedefはなるべく使いたくないわけよ
＞あれは型を隠蔽してしまうから、もちろんそのために使うんだけど


型を隠蔽？はぁ？

typedefは
実装を抽象して、
抽象データ型に近づけるためのもの。

アセンブラで16進コード弄り倒す人間には、関係ないけどなｗ

>>109
隠蔽するじゃん

>>106
ｶﾞｯ
ｶﾞｯ

http://61-26-231-161.rev.home.ne.jp/
ｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗっっうぇっｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ

>>111
typedefは、型を定義するもの。
データ構造の実装を抽象＝隠蔽して、
宣言的なデータ構造に近づけるのが目的。

もちろん、16進ダンプおっかけるような仕事には無関係だけどなｗ

アホか？>>114 >>110

ほっとけ

>>115
おまえが本当に馬鹿なのはよくわかった。消滅しろ

あぁ、またやってる、やってるｗ

ここに常駐してるバカは、
概念と単語の結びつきが特殊だからな。

"int *p"の"int *"が「型定義」と妄想しているのだろうな(ぷ

つ　http://www.google.com/search?hl=ja&lr=lang_ja&ie=UTF-8&oe=UTF-8&q=typedef+%E5%9E%8B%E5%AE%9A%E7%BE%A9&num=50
　　typedef 型定義 の検索結果のうち 日本語のページ 約 15,600 件中 1 - 50 件目 (0.15 秒)

>>115-116　ｶｺｲｲ

>>117-119
素人イジメ倒すの（・Λ・）ｲｸﾅｲ。

もっと、お母さんみたいに優しく教えなきゃ、かわいそうだよ

スマソ、首吊ってきます・・・

>>122
むしろ逝�`

てｓｔ

http://127.0.0.1/
ｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗっっうぇっｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ

http://192.168.0.1/
ｗｗｗｗｗｗｗｗｗｗｗｗうぇｗｗｗっっうぇっｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗ
ｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗｗうはっｗｗｗ

>>126
http://192.168.0.1/
ﾜﾛﾀ

むしろで逝�`

>>96
それはあなたの持っているコンパイラのstddef.hがそうなってるってだけでしょ？
規格でそう実装しろといってる訳じゃない。

空ポインタがアドレス0の環境なら>>84で十分。
違う環境なら違うように書くでしょ。

char mozi[] ="unkounkounko";
int sum;

for(int i=0; i < 12; i++) { sum = sum + mozi[i]; }

このようにすれば変数moziの1バイトごとの合計値は求めれると思うのですが
2バイトごとに求めるにはどうしたらいいでしょうか？教えてくださいお願いします。

すいません聞く場所間違えました

おまえらに聞いた私がバカでした

>>132
>>130のこと？
かわいそうなので解答。

for(int i=0; i < sizeof(mozi)/sizeof(short); i++) { sum = sum + ((short*)mozi)[i]; }

>>133
すいません、4バイトの場合も教えてくれませんか？

すいません解決しました

いいえ解決しました

こんな板で聞いた俺がバカでした。

まとめ
一、型修飾子と間接参照演算子がカブっている。
宣言系と演算系の性質の全く違う記号がカブっている上に
型修飾子を型につけても変数名につけてもいいという
無意味な自由度のせいで
余計に見にくくなっている。

二、積の算術演算子とカブッている。
性質がまるで違っていて
他に使える記号があるのになんでわざわざ
算術演算子とカブらせるのか。無意味に見にくい。

文句をいうだけなら誰でもできる

開発者が何でも"*"を使いたくて仕方がなかったんだろう。
そこでオーバーロードですよ。

* はアセンブラ由来じゃなかったっけ?
もともと参照の意味で使ってたとか

ｽﾏｿ
上で既出だった…

p(hoge)

無理に記号じゃなくてモナー
point( )とか
refer( )とかでよかったんでは。

point()とかrefer()とか、それじゃ関数じゃねぇか

ついでに add() とか sub() とか call_function() とかもよろしくな。

ﾏﾝﾄﾞｸｾ

型付きポインタ型変数と、非ポインタ型変数の　
記述上の区別がないのは煩雑だと思わないか？

int型ポインタ型の変数と、ただのint型変数を
記述上で全く区別しなくていいわけだ。

どっちも　"a" だとか "b" っていう名前だけで定義できてしまう。
記述を見ただけじゃ型付きポインタ型変数か普通の変数だかもわからないし
指し型もわからない。

$でも何でもいいから
せめてポインタ型かそうでないかの区別くらいあったほうがいいんじゃなかろか

ポインタ変数の宣言方法を変えればいい。

pointer<int> pi;

悪くないけど、頻繁に使われる分字数が気になるな…
ここは例外として
*<int> ptr;

でOKとか。*は型名って事で。
ptr->deref, ptr = var->ref ...

ミスっち。アロウ演算子じゃなくて.だった。

[宣言]
// ※　ポインタ型変数は、変数名の先頭に
// 　"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

算術記号としての * を廃止します。
今後、掛け算には新たに x を使用します。
変数名としての1文字単独の x は禁止します。

>>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;
}

>>154
離して書けよバカ

>>158
既存のコードも全部そうするのかよ。
そんなクソ文法を考えるセンスが素晴らしいな。

Javaみたいにコンパイルオプションつけとけばいい

演算子はくっ付けて書きたい俺様が来ましたよ

接頭辞にpをつけなきゃエラーにするってのはすぐにできそうだな。

>>161
演算子をなんでもくっつけられると思ってんじゃねーぞ
ポインタ同士の割り算は離して書くだろうが
括弧をつけるとか言い訳すんじゃねーぞ
ホントお前は知恵足りんだな

なんだこの馬鹿は

>>164
悔しかったら煽りじゃなくて反論をしてみせろ

第三者から言わせてもらうと
悔しがってるのはお前だろw

ちょっと批判されたくらいで熱くなり過ぎ。
お前がいいと思うんなら勝手にそう思ってりゃいいよ。

>>162
ハンガリアンのごとく嫌われそうな希ガス

>>166
第三者からみるとどうでもいい

つーか、pで始まる識別子を使いにくくなるという時点で却下。

>>163
まず
>ポインタ同士の割り算は
「頭悪いなー」と気付かないと。

ポインタにpをつけるのを義務にしちゃうと
ポインタのポインタはppに
ポインタのポインタのポインタはpppに
となっちゃうんですかねやっぱり

int****ppppX;
ｲﾔﾆﾅﾙﾅ・・・

しかしそこまで*が並ぶこともないだろう。

>>172
*の代わりにpを使うんじゃね？

〜型のポインタのポインタのポインタのポインタの…
などという
ひとりよがりの型を作るやつは
スパゲッティと同じで嫌われそう

>>148
宣言時が違う

>>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
意味わからんな。
改良なんて誰がしたっていいだろ。
こうしてみんなで意見を出し合えば、
やってくれる香具師も出てくるってもんだ。
グダグダ言ってないで君も何か案を出しなさいよ。
もしかしたら開発言語界の寵児になれるかも知れんよ。

うはｗｗｗｗｗｗｗｗ他力本願全開ｗｗｗｗｗｗｗｗ

２ちゃんで他力本願とか指摘されてもなｗ

Javaみたいに、本当はポインタなんだけど
ポインタであるということを意識させないのは
すごい画期的なアイデアだと思うんだが
>>183はきっと気づいていないんだろうな

その件に関して、Java に新規性はない
C 以前から参照渡しの言語はあったが、C はそれを選択しなかっただけ

アイデアを出した所で、実装が出来る人間はそんな事には確実に興味が無い
何で今更互換性を無視してまで C を改良しなくちゃいけないのか…

>>187
これだけ多くの人がつまづき、バグの元になっている現状を見なさい。
ポインタという欠点を放置しておくことはC言語業界の損失だよ。
解決できれば、互換性を捨ててでも乗り換える価値がある。

>>188
C++でもポインタを生のまま使いたがる人の存在はどう説明する?

>>189
それは単に保守的なだけと思うが。
無理にC++を使わされてるCプログラマと思う。
彼らは被害者なのだから、いたわりなさい。

>>186
ポインタであることを意識しないと非常に不安なんだが…。
つーか、意識しない人間が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
バグを0にできると信じてる方ですか？

>>202
＞参照やSTLはポインタよりも使うのが難しいと思う。
Javaについてはどう思う? 一般的にはCより難しくないと言われているが。
#あれは私にとってはポインタを生で触れなくて使い難く感じるのだが。

> 一般的にはCより難しくないと言われているが。
あれはガベコレあってのことだからなあ。

>>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
ありがとう
お礼に グーグルで「ポインタ」で検索してみて

イメージ検索で

犬がひっかかりますた！

こんなんでました
http://images.google.co.jp/images?q=%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF&hl=ja&lr=&c2coff=1&sa=N&tab=wi
http://www.limo.fumi2kick.com/tips/gtk_sprite2/spr2_screen1.jpg

本則では先頭const禁止ってなことになれば少しは混乱が減ると思ふ。
当然、互換性の観点から、デフォルトでは先頭constは警告なし。

が、ｲｨと思うんだけどなぁ・・・

一つのことをやるのにいろんな記述方法があることがポインタの問題点だ。
そんなんでは人によりコード記述の流儀が違いすぎて
バグの元だし保守しづらくなる。
やはりCOBOLのように、誰が書いても同じコードになることが
業務系開発言語には最重要に思う。
てか、システム記述言語であるCを業務系に使うことが誤りなんだよな。

業務なら決めておけばいいだけ

>人によりコード記述の流儀が違いすぎて
>バグの元
流儀の違いがバグの元になるわけね〜。
解釈する能力が足りないからだろ。

>>242
＞やはりCOBOLのように、誰が書いても同じコードになることが
ほほぉ?

誰が書いても同じコードになるプログラムなんかねーよ・・・

Cのポインタだけでなく、自由度が高いと複数人でコードを書いたときに
わけがわからんことになりやすいって話だろ。

コーディング規約レベルでは守らないやつも出てくるし
言語である程度自由度を下げておくというアプローチもありでしょ。

>>247
それは判るが、COBOLを引き合いに出した>242は問題の本質を判っていない気がする。

人の流儀にはしたがわねーって流儀の奴が多い業界だからね。
あ、その業界でもそうかな？

>>45
’＄’（ドル記号）は通貨記号なのでソースの可読性を下げると考えられたから。
だた、＊＊ｐ＊＊＊ｎ;ってソースを見るとゲギョ！っと思うのはごもっとも。

以降、こちらでお願いしますです。<(_ _)>
C言語なら俺に聞け! Part 110
http://pc8.2ch.net/test/read.cgi/tech/1120596481/l50

>>1
通常の変数のポインタは不自然じゃない。
それよか、関数ポインタの方が不自然。

int (*pproc)(void); // 関数ポインタ定義
int proc(void); // 関数プロトタイプ

pproc = proc; // ポインタコピーして
pproc(); // ポインタから実行

宣言としては、 (*pproc)() と proc() はint型を示すものとして理解できる。
ならば、 *pproc と proc はintを返す関数として理解できる。
なら、

pproc = &proc; // ポインタコピーして
(*pproc)(); // ポインタから実行

の方が自然じゃないのか？？？

>>250
へっぴりジョブスは引っ込んでろ！

>>252
sageてるから今回だけ許したる・・

>>251
昔は後者のようにしないと駄目だったようだが、
自然だということ以外メリットがないということで、
前者のルールになった。

ちなみにこんなこともできる。
(*******************printf)("hoge");

ポインタ参照を@とか使われていない記号にして、かつ後置にすれば問題が無かった予感。
ついでにアドレス参照演算は@前置とかにすれば統一感がとれて矛盾も生じないと思うが。

int p@; // ポインタ宣言
@int p1, p2; // これでもポインタ宣言としてOK
int n; // 普通の変数
p = @n; // ポインタコピー
p@ = 10; // ポインタ参照で変数を変更

アロー演算子なんて取ってつけたようなふざけた演算子も要らなくなるし。
不必要な括弧の連発もしなくてすむし。

int pproc@(void); // intを返す関数ポインタ宣言
[email protected] = 20; // アロー演算子不要

Pascalがそうか。

てか間接参照は[0]でいいじゃん。
C++の純粋仮想関数だって=0みたいな気色悪いことやってるんだし。

>>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で説明出来るのか？
ということなのだが。

そんな昔のこと言われてもなあ　あははははははははは

>>265
リファレンスとでリファレンスがちゃんとマップされてるから

>>265
リニア(配列の類)なデータを渡されてそれをアセンブリで操作することをやったことがある？
無ければ直感的にはわからないかも。

言語仕様でそう決めたんだから>>1が幾ら文句言っても何も変わらない。
以上


以下、このスレは新言語原案募集スレになりました。（w

C言語のポインタ部分だけを改変した自慰言語の開発に取り掛かろうと思います。

>>269
なんでそう決めたのかの経緯を知ることも重要だろ

どうせK&Rやコンパイラ製作者のエゴだろ

Cの謎仕様はいくつもあるけど>>1のはおかしいとは思わないし
代案の方がよっぽど変。

>>270
E言語とF言語は欠番ですか？

>>274
→H→愛→自衛

自慰→Ｈ

現在、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.高級言語ではポインタを使わない方がデータ操作をスマートに記述できる
との理由のため、ポインタの使用を禁止しているコーディング規約が多い。

おれの予想では、5年後には、ポインタの使用は禁じ手になると思うな。
>277 ようなコーディング規約が各社で運営されて
"それでもポインタ使う派"と、"新しい記述を推進する派"で、2ｃｈで終わりのない論争を
続けているだろう、と予想した。

さあ、だれか、 >277 を否定してみてよ！

さあ！さあ！！さあ！！！

オレがその会社のプログラマなら、そのコーディング規約に従う。
goto文やポインタを使わなくても きれいなコードはそれなりに書ける。
この程度の下駄なんてたいした問題じゃない。

本当にひどいコーディング規約になると
構造体はいつでも必ず実体で扱うこと とか
C++なら継承禁止 とか枚挙にいとまがない

それよりも、未だに一行80バイト、コメントは41カラムから、変数名は20文字以内、
などの戯けたコーディング規約に早く消え去って欲しいと思う恭子の頃。

おまえら、Java使いだろ？

>>277
std::vector<T>::iteratorは？

ポインタがだめなら
std::string str = "abc";
もダメなんだよな？

>>280
いや、それはなるべく守ろうよ
コメントはどうでもいいとして

>>283
そんなもんでポインタポインタ騒ぐヤツ居ないと思うが・・・

>>277以降のはコピペだね。
どっかで見たよ。

一行80バイトは馬鹿馬鹿しいね。
行を折り返すことで発生するトラブルもあるんだしさ。

>>286
でも、80バイト以内に収まるよう「心がける」ことは
決して悪いことではないと思う。

多少はみ出たって気にはしないけど

やり過ぎは良くないが、こだわり過ぎて雁字搦めになるのも良い物ではないってことか

規約というのは常に最下位レベルに合わせて作成される

タブストップが８でない場合、インデントはスペース使ってくれ。
何も入っていない人様のWindowsでEUCの入ったソースを見ようと
思ってIEに食わせたら眩暈がした。

>>287
甘いな、1行80バイト以内じゃない、1行80バイトなんだ。

甘いとか甘く無いかとかいう問題か？（爆笑）

>>292
そのプロジェクトに参加して初めに組んだプログラムは、ソース整形ツールだった。

一行が長くなる原因・・・

10個近くの引数を取る関数・・・それ自体がそもそも間違った存在なのではあるけれど、
そういうのがある以上、一行80バイトを越えてしまうのは仕方ない。
一行一引数での書き方もあるが、それはケースバイケースで使い分けるべきで、
なんでもかんでも、どちらか片方の書き方に統一しろというのはナンセンス。

中カッコのネストが深くて行頭にタブが10個以上入っている・・・
それは関数が大きいからなのだが、時には大きいほうが良い場合もあるからなぁ。

>>290
インデントにスペースを使うのは勘弁してくれ。
もっと最悪なのは、インデントにタブとスペースを混ぜて使ってることだが。

タブにしておけば、見る人が好きな文字数にして見ることができるじゃないか。
スペースを入れた瞬間に、そのソースのタブのサイズは固定になり死ぬ。

>>294
好き好んで混ぜるというよりIDEのエディタがタコで混ざるパターンが多いかも
改行したときの自動インデントとタブ入力の扱いが違ってたりとか

>294
そういったビューアでもツールでも標準でついていれば文句は言わん。
IEにタブ ストップの文字数設定する項目あるか？
劣悪な環境下でもなるべく可読性をそこねないコードを吐けって話だ。
タブ ストップ 文字数を自由に変えれる環境にentab、detab追加する
くらい簡単だろ？

そもそも何でIEで見ようとするの？
IEにそういう項目がないからって噛み付く意味がわからない。

(´Д⊂ｳﾜｰﾝ
だから劣悪な環境だと・・・

インデントはタブであって欲しい人がいるようだが、Delphiなんかは
デフォルトのインデントは２だがタブ ストップは８文字だったかと。
んでIDEが吐いたテキストを便利なエヂタで開いてタブ文字数
変えると・・・

>>295
そのIDEは余りにゴミだな。

劣化unix使いで、viを動かしている端末エミュレータ間でコピペする阿呆がいる。
その場合、XWindow上だと空白でコピペされるんだよね。
よって、インデントがタブか空白かでオリジナルかどうか判る罠。

>>297
EUC→MS-Kanji変換を何もしなくてもやってくれるからだよ。

何もしなくても変換してくれるとして何でIEでなければならないのか不明。

>>1
ごめん

危険な無料ウェアを勝手にインストールする事が禁じられているから

セットアップ終わったばかりのWindowsでソースを見る必要が生じることもあるでしょ。
実際客先であったんだけど。

危険な無料ウェアがダメなら市販ソフトを買えばいいじゃない。

市販でも、怪しげな怪社の祖父とは禁止されているかと。
ソース次とか・・・

思ったが>>304は上の馬鹿さ加減に嫌気がさしている・・・んでは？

M$だって補償してくれる訳ではないんだけどねぇ。

そんなくだらないことのために、
ソースの保守性を下げるのかよ。

馬鹿じゃないの?

っていうか、なんでWindows環境なのにEUCなんだよ。
そのソースをWindows環境に持ってくる前にEUCから変換しろよ。

そうだね
UNICODEにすべき

構築、稼働はLinuxだけどクライアントへの説明などはWinってぇのは普通かと。
nkfとか入ってないのは前レスを。

いや違うな・・・

ソースはタブで書いて、
表示用にタブ→スペースに変換してから、Windows環境に持っていけばいい。

をっ！EUCって何だか分かったな！
勉強になっただろ。

貫通力の問題なんだが・・・
果てはCP/M(って何？)から今の全てのプラットフォームでおk

つか、タブ・スペースごときで保守性とか言ってんなよ...

つーか、おまいら、ポインタの話にもどせ。１行の文字数は別スレでやれって。

>277の反論はないのか？

>282 >283の言う、std::string などは ポインタ排除の方向に
Ｃ言語がかわりつつあることの象徴だろ。

ファームウェア書いたことある人いますか？

どうでもいいけど引数の参照が
void hoge(int &ref)
{
}
void hogehoge(void)
{
　　int a;
　　hoge(&a);
}
みたいにならんかったのは何故？
いつだったか参照に気付かずにバグりそうになった事が…

>>318
あなたはこう書きたいですか？
std::string str = "HogeHoge";
&cout << &str;

>>316
C/C++ではポインタを捨てることが出来ないと言いたいんだが…。

ポインタを使いたくなかったら他の言語に移ってください。
それで丸く収まります。
あなたの仕事がなくなろうがしったこっちゃありません。

つまり、文字列型がない以上、const char *を受けるコンストラクタが必要になるということですな。

それ以前にC++の参照は仕様が腐ってるから
ポインタ排除は無理だな。
仮にstringだか文字列型を言語仕様でサポートしたとしても。

>>316
> >282 >283の言う、std::string などは ポインタ排除の方向に
> Ｃ言語がかわりつつあることの象徴だろ。
いつのまに，C言語にstd::stringが追加されたんだ？

触ってやるなよ

>>316
反論はあるけど、規約に反論しても仕事は進まんし。
規約はそれを作った人間／組織の技術レベルを反映するから読むと面白い。
それだけだよ

>>316
gotoはエラー処理以外は使用禁止なら無問題
あんまり使わんけどな。
ポインタ禁止って、、、２つ以上の値を返したい関数はどうやって作ればいいのだ？
もちろんCだから参照はないよな？

つ グローバル変数

いや、ネタはいいから

つ 構造体

それじゃまるで、ポインタを隠すことに終始したために見通しの悪くなったJavaの劣化版じゃないか。

C言語でポインタを使いまくり
見かけ上ポインタを考慮しなくてよいものをC++で作る
なんか最近のトレンドっぽいね

うちの会社は組み込み系でリアルタイム性バリバリ必要なんで、
C言語でないとパフォーマンスでなかったんだが、
さすがに生産性を考えてC++に移行しつつある。

いまどきは、CPUもコンパイラも賢いから
組み込み系でも抽象度の高いほうへシフトしていっている。

ちなみにD&EにはC++の目標の1つとしてCと同じ速さで動くというのも挙げられている。

>>326
＞gotoはエラー処理以外は使用禁止なら無問題
多重ループ脱出用途は駄目ですか？

まだやってたのか

try-catchもbreakもcontinuもgotoじゃん
近代言語でこういうのはgotoで実装してそうだなってのは
基本的に全部OKなんじゃね？

whileあるのにgoto使うバカはほっとけばいいし

ループの中のswitch-case文の中からループ脱出したいときどうしてる？

gotoとポインタに関連ないからスレ違いだと思うよ

while(hoge){

try{

throw "ループから出させよやｺﾞﾙｧ!!!";

}
catch(char *e){
if(strcmp(e,"ループから出させよやｺﾞﾙｧ!!!")==0) break;
}

}

C言語でないの？

スレタイを読めない人がいるとは思いたくないが

わかったようするに>>1は頭悪いんだ
すげー理解力

Cもポインタやめてリファレンスにしようぜ

議論の結果はどっかにまとめてうｐしとけよ

c言語のポインタの文法は確かにおかしい。直感に反する記法を強いられる場合がある。

c言語の教師になる人や、コンパイラを作成しようとする人は、この事を意識する
必要がある。しかし、このことに気づかないままCをマスターする人もいるだろう。
普通にプログラムをする人には、文法のおかしさに気付かずに済めば、寧ろその方が
幸せかも知れない。

ただc言語のエキスパートが多数存在し、有益なコードが大量に作成されている事実
がある以上、もし「文法がおかしいから国際語には向かない。」といった発言があれば、
それはは間違いだし、謝罪し訂正するべきだと思う。

>>345
慎太郎かよｗ

>>306
コンピュータ言語と違って自然言語は、
使っていくうちに変化するという特徴があるので
文法のおかしさが減ったものほど広く使われるようになる。
また広く使われるほど文法のおかしさが減っていく。

まぁ確かに、1から100まで規則性が認められない言語もあれば、
日本語のようにかなり規則性に富んだ言語まである。
フランス語が偶々前者に近いからといって、フランス語全てが
文法がおかしいというようなニュアンスの発言はお郷が知れるというものである。

フランス語は数字もまともに数えられない欠陥言語

お偉い人はつくづく要らんことばかり言いますな

数学を勉強する者にとっては、第二外国語は
ドイツ語よりフランス語だよな。
フランスは数学の本場だし。

多重ループ脱出もそうだけど、
1回しか回らないループ（つまりループじゃない）を作って
エラー処理時にbreakするってのは
邪道なの？正道なの？

do {
：
if (…) break;
：
} while (0);

ってこと？別にいいんじゃね？
でも一般に関数化してreturnの方がよさそう。

>>353
ふっふっふ・・・
関数作成数に上限があるコーディング規約なのだお

>>354
きもっ！

別にいいんじゃね？
変な規約。

オーバーヘッド対策か知らんけど、裏目に出るだろうな

素直にgoto使えばいいのに

>>352
それをやったプログラムで・・・

for(...){ //意味のあるループ

do{ // try代用のループ

if(...) break; // 意味のあるループを抜けるつもりで書いた

}

}

というミスをして１時間くらい悩んだ経験あり。
よって駄目・・・と言いたいが・・・
しかし関数化すると処理が見通しにくくなるし・・・

やっぱ特定のループを指定できる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];
のようにしてる漏れは逝ってよしですか?

ああ、delete card;　が最後に来ます。

もう一つ上のクラスを作ってそこのデストラクタで
解放するようにした方がいいと思うぞ。

>>353
関数の途中からのreturnを禁止しているコーディング規約もあるぞ。

何らかの片付け処理が必要なものはデストラクタでやるようにしていても、
returnで抜けさせてくれないのよ。そんなだから、例外も投げるのは禁止されてる。

C++なのに・・・と激しく悶える。

>>368
が正しい

>>369
はやっちゃいけない

>>371
は有り

>>372 return禁止
基地外じみてるな。
しょうがねぇから用もねぇのにフラグ変数増えてハマる・・・
規約を決めた根拠がわからん。

class CCard
{
private:
　　Card card;
public:
　　CCard() { /* インスタンス生成及び失敗した場合の処理。 */ };
　　~CCard() { /* メモリの解放 */ };
}
CCard::CCard()
{
　　card = new Card[52];
}
CCard::~CCard()
{
　　delete[] card;
}

OO的には普通こんな感じじゃないの？

老婆心ながら、ジョーカーの存在を忘れてるよ君たち。
カードの数は５３でそ？

だってちちならべにジョーカーは使わないんだもん

>>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;
}

>>379
馬鹿ですか?

return禁止なのは、C時代の名残りだね。

openしたものをcloseせずにreturnしたらヤバいでしょ。
returnと書くところで、それぞれcloseしたら、closeし忘れも出るしね。

調子に乗って書いたら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文字制限つき。

>>383
いや、それだとインデント制限もある場合に難しくなる。

>>384
わはは、最初はライトでサンプルを書こうと思ったのが途中で挫けてリードになったわけだ。
いいじゃん、察してよ（ぉぃ

>>385
たしか規格にで処理系はブロックの入れ子を最低15認識できないといけないと書いてあったはず。
となると逆に言えばそれ以上の入れ子のソースはやらないほうがいいと言うことだろう。

＃インデント15はかなり多いと思うけど。

そういえば一行の長さは最低519byte以上を認識するべしとも書いてあったような
・・・んなもん書くもんか

どっかのスレで、一行数KBytesのコードを見たってコメントを見たことがあるが。

人間が書いたのではなく、
難読化のツールの出力だったりしないか?

>>388
8タブだとえらいことにw
>>389
標準的なBUFSIZ(512)-CR-LF-EOSで509バイトかと。

ポインタの話・・・

>>392
ポインタの話は今のままでしょうがないでFAじゃないの?

で、509バイトがどうかしたの？

>>393
519バイトはおかしいよね という話？

タイプミスだと思ったんだけど、とりあえず突っ込み入れておきますた。
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だと思う。

小学校で習ったことをがんばって思い出すと、
それは倒置法っていう奴らしい。

これからはなるべく理解しやすい発言を心がけるよ。
正直すまんかった。


紙媒体ではなく電子媒体または二次記憶媒体での文書保存おｋで
ISO9000取得しているところって多いのかな？

うちのISO9000の内部監査では、
監査員が見せてと言ってすぐに見せられれば電子媒体OKになってます。

某映画の様にzipドライブとかオープンリールでそのままは論外ってことだね

必ず紙媒体が必要だな。
電子媒体はマシンがとらぶってダウンしてたら見れなくなるんで不可。

じゃあ>408は？

>>408-410
thx

408は内部監査と限定してあるから、保存用は別ということかな。
設計審査とかのときに重いファイルを持ち歩かなくてよい、目で検索する必要がないなど、
紙より効率いいなぁ。

>>410
（一時的）保存媒体さえしっかりしていれば参照するマシンは何でもよいかと。

長期保存が問題になるような希ガス。
CD-Rに保存するとして、文書保有最低年数は保存データを保証するメディアでないとダメ
だろうし、数年後に読み取り可能なハードが存在するか？という問題もあるだろうし・・・

ちょっと前まで保存用は紙でした。

最後に紙に印刷して倉庫にしまっていましたが、
倉庫から出してくるのが面倒なので、
後から参照するときも紙は使わないです。

んで、その先がアホな話しでして・・・。
紙に印刷して倉庫番に渡すという社内ルールはそのままに、
倉庫のスペース削減のために、紙ではなく電子化して保存するようになったんです。
紙で渡したものをスキャニングして保存、紙は廃棄。
倉庫から出してというと、紙に印刷して渡してくれる・・・orz

ちなみにうちはCD-RはCD-ROMのマスターとして業者に渡す時だけで、
基本的に保存はMOを正副2枚ずつ保存するようになっています。

CD-Rなら良いのかもね。
うちはMTだからダメなんだよ。
（大型コンピュータの磁気ディスク装置にかけるなんてすぐにはできない）
そういや文書はマイクロフィルム化してもよいことにはなってたな。

なんかもう激しくスレ違いですね

スマソ

>>413
ワラタ
MO二重化はOKか。
参考になります。
>>414
マイクロフィルムは耐用年数が非常に長いみたいね。でも手間が・・・
>>415
夏厨が読んだら少しはタメになるかと。

>>417
うちは納品物は全部正副の２部づつだけど？
電子媒体に限らずソース（紙媒体）、仕様書にいたるまで全て。

品質管理の一環で？

品質管理とは関係なく常識かと。

話の流れからして、品質管理上必要な文書長期保存の媒体がMO一枚では心許ないので、
正副の二枚に保存することによって電子化できたということだと思ったが。

それはそれとして、
納入物件に紙媒体のソースがあるというのが気になる。

話の流れからして、品質管理上必要な文書長期保存の媒体としてMO一枚では心許ないので
正副の二枚に保存することにより電子化できたということだと思ったが。

それはそれとして、
納入物件に紙媒体のソースがあるというのが気になる。
もしかすてF通？

どうでもいいやんそんなこと

別に不実に限らんだろ。

富士通のCMをやっていた工藤静香の曲の歌詞に、
「不実です」というのがあったが、「富士通です」に聞こえたな。
前後の詩の文脈とも相まって、えぐい話だ。

いや、でも電子媒体のみで運用できる？
もし印刷したりして持ってたら版数アップとかで
最新版と内容がずれることがあり、監査で引っ掛かるぞ。

C++ならあるんだよな>>int　&a
さて　.cppで
int*　aとはどういう違い？

別名とポインタ

別名はポインタ型の変数に，自動的に*をつけて
逆参照していると思っていいのではないかと思う．

foo (int& a) {
a = 1;
}

は，

foo (int* a) {
*a = 1;
}

と同じ．別名だとa++みたいな
ポインタ操作ができないからこちらの方が安全．

最近は、「別名」なんてわけのわからん訳をするのか？

前橋って人がある本で『C++における参照は本来「別名」(alias)とでも呼ぶべきものです』って書いたのが原因かも
まぁこれが何処か別のところからの受け売りである可能性も否定できませんが

428につられて書いたけど, たしかに，
上で書いた引数の例だと，別名って言わずに
参照渡しと言って，そのまま変数を参照って
言うことが多いね．

でもこれはちょっと混乱の元かと．
普通の変数であってもデータを参照しているわけだし．

初心者に言う時に良く言うヤツ多いな、別名って

参照って単語が使いづらいんだよ
Cのときは「ポインタを使って参照する」とか
言ったりしてたのに参照そのものが出来たら
今まで言ってた参照をなんて言いかえるのか

だがポインタを使って値を参照することに変わりは無いわな

>>435
だから、参照に参照という名前をつけてもいいんだけど
それだと参照するときに参照という単語を使うと
参照がダブってしまうので今までのただの参照と
誤解を生むんだよ

参照のオンパレードだな

そこで意味も無くリファレンスとかエイリアスとか横文字を持ち出してお茶を濁すのはどうだろうか？

初心者を煙に巻く以外の意味は全く無いな

初心者を煙に巻ければそれで十分。
煙に突進してくるくらいの気概の無い初心者を振り落とせるからな。

たしかに参照って言葉は用語として用いるには意味が広すぎて嫌だな…
「別名」のほうが混乱がないと思う…

しかし別名という考え方が一般化すると、次は普通に定義された変数が本名とか呼ばれそうな予感。
・・・でも、そんなに弊害は無いかな？

別名とくればそりゃ普通に本名だろ

仮名・堂島 とか

とんでもない方向に…

「アドレスを示すポインタ」が基本だろ？
ポインタはポインタ。

ホワイトボードに書かれた項目をレーザーポインタで指し示す場合、
参照やら別名とか岩ﾈｰだろ。

要は、アドレスを表すのか、アドレス内の値を表すのかって事だけなのに、、、

お前ら、初心者を振り回すのに必死だな。

ポインタはアドレス

>>445
何の話をしておられるのですか？

俺の会社では、レーザーポインタとは呼ばずに激光指針って呼んでるよ。

俺はレーザーポインタって呼ばずに赤い点って言ってるよ

>>445
アドレスだけがポインタだと思うなよ小僧

なんだよＣ爺

>>450
ポインタだけがアドレスだと思うなよ、の間違いですか？(･∀･)ﾆﾔﾆﾔ

>>452
間違いじゃないよ（ﾟ∀ﾟ）

おまん子が変数

おちん歩がポインタ

{
おまん子　小倉優子,谷亮子;
おちんぽ * 俺;

俺 = &小倉優子;
ASSERT((*俺)(ｽｺｽｺ))

俺 = &谷亮子;
ASSERT((*俺)(ｽｺｽｺ))　←ここでエラー
}

楽しいか？

ポインタだろうが参照だろうが吐かれるコードは一緒だろうが。
アプリ屋ばっかだな。

誰に対してのレスだ？意図も不明

どっちでも同じってことだろう。
が、ソース上の違いが重要なのでは？

>>458
ファーム屋にはそこがわからないんだよ
良くも悪くもアセンブラの延長としてしか
Cを使ってないからな

C:中級言語
C++:中級言語としても使える超高級言語。
当然、基本クラス設計者は神のように下々を見渡せる必要があるが、
んなクラスは見たこと茄子（単純なのは除く）。
言うまでもなくMFCなんぞ論外。

C#標準化って何？

高級言語の意味を理解してない馬鹿

>>459
PCの発展や最適化技術の発達によりパフォーマンスよりもソースの可読性の方が重要視される場面が出てきたということさ

>>461
禿同

……けど、C はかなり低級よりな高級言語だぞ

>>462
そこでひまわりですよ

「アセンブラめんどいから強力なマクロ作りまスタ。」が、Ｃ言語なんだから、おおむね正解。

C言語作ったのって「UNIX移植するのめんどいから」ってのが理由じゃなかったっけ？

そう。
動機がその程度の言語だから
いい加減な作りがあちこちにあるのは当然。
なのに開発言語としてメジャーになってしまったのが
コンピュータ界の悲劇。

他の言語開発者みてるとたいてい理想ばかりが先走って実用性は二の次三の次なﾔｼばっかなのが不幸をさらに加速させたよな

>>467
どこがいい加減なのか書いてみろよﾌﾟ

467ではないが一つあげられるのは演算子の優先順位。

>>467-468
そりゃOSを書いてる言語だから、メジャーになるだろうよ。

Cを習得しないと、目の前のマシンにUNIXを移植することができないし、
改変することすらできないわけで、必修言語なわけですよ。

>>470
いい加減と言うより、自分が覚えられないだけじゃアルマイカ？

>>471
C使いの誰しもがUNIX野郎だとは思えないけどna
つか,なんでOS(ry

単にコンピュータとの親和性が高い（アセンブラに近い）という点に尽きるだろ
それだけ

演算子の優先順位がいいかげんって、どのへんがいいかげんなんだ？ﾌﾟ

>>474
i=i++;

>>475
それは ++ の方が優先順位が高いが、単に ++ が元の値を返す性質があるだけ。

ビット演算子の優先順位が比較演算子よりも低いのはおかしい。
論理演算子が存在するのに、比較演算の結果をビット演算する用途なんてそう頻繁にはないだろうが・・・。
論理xor演算子を導入した上で、ビット演算子の優先順位は上げるべきだった。

あとは散々外出だけど、ポインタ参照演算子は前置ではなく後置の単項演算子にすれば文法がかなりシンプルに
なるのに、前置したため話が面倒になってる。
前置の良い所はメンバポインタを記述するのに括弧がいらないことくらい。


あとC++の話になるけど、テンプレートの括弧に<T>をつかってしまったこと。
× TemplateClassA<TemplateClassB<int>>
○ TemplateClassA<TemplateClassB<int> >
　　　　　　　　　　　 このスペースがｷﾓｲ。↑

まぁ探せばまだまだあると思うが。

根源的な話をすれば、LL(1)文法にしなかったという点で、リッチーは言語設計者としてのセンスが無い。

関数の()の最初と最後にスペースを入れる俺にとってはそんなスペースｷﾓくも何とも無い
てめぇの趣味だけで語ってんじゃねぇよ

>>478
そのまま返される気がするのだが…

文法の話と読みやすさの話を混同しないようにしよう

>>478
関数の( )の前後はスペースの有無にかかわらずエラーにはならんが、多重テンプレートはスペース入れないとエラー。
関数はお前のような趣味をする余地があるが、テンプレートは趣味が許されない。しかもキモイ。

< や > を多用しすぎなんだよな。
a->b とか、 a-->b とか、 a>-b とか、 a--->b とか・・・

まぁ、ｷﾓｲ＝いい加減
というのは成り立たない。
481はｷﾓｲ

ｷﾓｲｷﾓｲ言ってるだけかよ481

記号の使いまわしが 気に入りません

カーニハンに謝罪を、そしてリッチーに賠償を要求しましょう

チョンうざい

>>475
そんな無意味なコードを書くな（w
せめて別の変数に代入すれ。

>>481
->以外解らんのだが

>>487
(a--) > b デクリメントと比較演算子
a > (-b) 比較演算子と単項マイナス演算子
(a--)->b デクリメントとアロー演算子

あぁなるほど、ってデクリメントとアロー演算子とか、普通()つけるだろ・・・

わざわざ分かりにくくて一般的でもない事例をあげて
使いにくいとほざけばいいと思ってる

ポインタの本を10冊以上買って読んでみたけど
さっぱりわからん。
なんかこう、フィリーリングが合わない。
アセンブラはわかるのに。
たぶん同じことをやるのに何通りもの書き方があるせい。

フィリーリングとはなんですか？

auth!
フィーリングだったぜ。
カナ打ちだからゴメンな。

カナ打ちだから

>>491
お前なりにポインタについて解説してみな
そうすりゃどこがおかしいのか見えてくるから

>>490
葉外道。いくらなんでも変換ミスったようだ

>>491
>アセンブラはわかるのに
で、ポインタはわからんと・・・

釣られてしまつた orz

>ポインタの本を10冊以上買って読んでみたけど
ﾎﾎｩ

このスレ パスカル使い多くね？
Oberon実務で使ったことある人いるのかな？

>>473
話の流れを嫁。

ついでに歴史の勉強もしろ。

ということにしたいのですね？

はい、ということにしたいのです。

かのようなこと、某の一存では決めることができませぬ

>>1
おかしいだのどうのこうの言っても何もならんのにな。
現実の言語仕様に黙って忠実に従うことだけを考えてきたが。
お主は、英語でも文法だの活用形だの発音だのおかしいと言ってる人物ですの？
それよりも$記号て何ですの？それとCなのに何でC++のコメント使ってますの？

原理主義者ですか？w

俺は++でも/*使っちゃってるけど、C99では//は本則ではないのん？
(てめぇで調べろ→漏れ

/*で書いとけば無問題なのでどうでもいいか・・・

まあ、たしかに>>1は自己中心的なナルシストだけどさ、Ｃで//をコメントとして用いたら、コンパイラーが怒るでしかし。

C99から//コメントアリだよ

俺がコメント書くと十中八九複数行だから/**/で書く

// で書いとくと、実験中に /* */でコメントごとコメントアウトできるから
便利だ。 さらにそれをもコメントアウトするときは #ifdef 0〜#endif だ！

>>509
#ifdef 0
でもいいけどね・・・
#if 0
のほうが

あ、そうか>>510の方がいいな

0がすでにdefineされている可能性をわすれちたよ

>>509,>510,>>511
おまいら、微妙に・・・

ただしくは「#ifdef <IDENTIFIER>」か

>gcc test.c
test.c:3:8: macro names must be identifiers

#defundefun

Cの本質的に糞なところはポインタの文法ではない。
文字列型をサポートしないのに文字列リテラルをサポートしてしまったことだ。
この安易な機能追加による不統一感は耐え難いものがある。

メモリ管理をしない言語っていうのも、どうかと思う。

>>515
全然まったくそんなことないよ？

>>515-516
VBすれば？

>>515はわかってない。

禿同

C言語の欠陥は・・・整数除算と浮動小数点除算の区別がわかりにくく、明示させるのも面倒なことかな。
Pascalみたいに、別の演算子にすればよかったのに。
あと、浮動小数点から整数への自動型変換も迷惑。情報が欠落する方向へ勝手にデータを変換するな。

>>521
Pascalをやっているとそのように思うのはもっともだけど。筋が違います。
Cは「プログラマは間違えない」という前提で設計された言語だから

でも浮動小数点から整数への暗黙の変換は確かにどうかと思う。

警告が出るコンパイラを使えばいいじゃない。

>>521=523
> でも浮動小数点から整数への暗黙の変換は確かにどうかと思う。

それ逆だから。何の事言ってんだ？

>>525
int i = 1.5;

そりゃ暗黙の変換以前の問題

つーか、小数の扱えないものにわざわざ小数型を持ってくるのが悪い

>>522
「プログラマは間違えない」という前提の代償が簡便な記法になるならともかく、
整数と浮動小数点数の型変換は除算の時いちいちキャストしなくてはいけなく、
逆に記述が面倒になっているが。

>>529
だから、んなーことない

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 となる。

とかの方がスッキリすると思わんか？
まぁ直感的に@が除算に見えない、という感覚的な問題は別として。

だから、んなーことない

って、何言ってんのこの池沼

池沼だからしかたがない

Cが嫌なら使わなければいいじゃない。

出た。オコサマの論理。

だれも「前提の代償が簡便な記法」とは言っていないし

int a = 1 / 3 * 3;

これが a==1 になることってありえる？

学生の作ったバグ入り最適化コンパイラならありえるかもな

>>538
ありがとう
おれが作ったのはバグ入り最適化コンパイラってことでFAみたいだ

>>539
いや、藻前が作ったのは有理数型をネイティブサポートした、誰も必要としていない高性能コンパイラだ。

確かにいらねーな。ライブラリで使えるならいいけど。

>>537
今のコンパイラーは、最適化するから、　/3 *3 の部分が無くなるよ。

>>537
普通の数学の決まりに則ればa==1こそ正しいんだけどな

>>542
釣り？

>>542
それは…つまり…
a = 1ってことですか？

数学的には
a = 1/3*3
　　　1
= -----
　　3*3

= 1/9
が正しい

何この池沼546？

>>542
いや、1 / 3は整数型同士の演算だから0にならないといけない。 

浮動小数点でもマシンイプシロンを考慮しなくてはいけない。

>>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がメジャーになったのが気に入らないってのが否定派の深層心理。

別に気に入らない訳でも否定する気も無いけど、Cにあまりにも欠陥が目立つな、とは良く思う。
少なくとも熟慮の上で設計されたエレガントさがCには感じられない。
なんとなく思いつきで作った言語って感じが否めない。

実際、最初はUnixを書くために作ったらしいしな。
そう考えればCはアセンブラに比べれば格段にましだ。

>>555
＞実際、最初はUnixを書くために作ったらしいしな。
まだそんな話を信じている馬鹿がいたのかｗｗ

>>554
たとえば？

考えてみれば、分数を表現できないのがおかしいよな。
なにか数式言語をネイティブサポートすれば解決。

構造体があるじゃない

>>556
色んなUnixの歴史を書いた本に書かれてることなんだけど、あれは冗談だったのか・・?

>>556
ええっ嘘なの？
コンピュータ界の歴史が変わる大事件だよ
ソースキボンヌ

ヒント:Unixも開発段階からそう呼ばれたわけではない。

当時はUNIXとは呼ばれていない → Maltics が頓挫したあと、まだ Unics と呼ばれていた時代か？
新規ではなく、既存のOSを改良するために開発された → 移植性を上げる為、極力アセンブラを排除するのが目的

>>563
それは私の知識と違うなｗ
Malticsのアンチテーゼの意味合いで新規に開発された。最初はアセンブラが沢山。
移植性を付加するため、アセンブラ部分をCに書き換えた。

>>563,564
×Maltics ○Multics

トリビア：
何でもできることを目指したMultics(<Multi)のアンチテーゼとして
開発されたことからUnics(<Uni)と名づけられた。

僕は配列として使うポインタ型作るときは
int a[];
と宣言してアドレス演算子を使わないようにした。
** の重複を回避するためなら a[0] とかいうアクセスもした。

これで掛け算の * と変数の * が混在しなくて済む。
a->b とするよりも a[i].b としたほうが、
デバッグ中に何番目のデータを処理してるか、
すべてのデータを処理したかどうかがはっきり分かるようになる。

データ依存のバグが出る場合はメリットが大きいよ。

プロセス間などのメッセージボディーのデータ内に、生のポインタ渡すのもキメエよな。

Windows3.1に謝れ

なんだ脳内か

>>566
仮引数でないときにはint a[]はポインタ型にならないのだがそのときの宣言には * がいるだろ。

>>570
そうだっけ。
そうかもね。

ハンガリー様でいいじゃない

int iMonar ;

int *ipMonar ;

>>572
そこpiMonar。
自己流なら気にしないでおくが。

piMonyar

piMomi

>>566
別に int *aで宣言してもa[x]で使えるわ

ttp://www.aromani.com/img/bana-/tintin.jpg
ティんティんマッサージ

ﾊｲﾊｲﾜﾛｽﾜﾛｽ

>>1-2
吹いた
余計にややこしくしてるし
ポインタとアドレスの区別くらいしような

定義と宣言の区別がついていないヤツ大杉。

最近定義と宣言が区別できるようになって大喜びの>>580

>>580の一言でハッとする>>583

ハッ

何この流れ。

今時Cなんて資格取得の為にリア厨が勉強するくらいのもんだからな

Cじゃなきゃ取れない資格って何？

>>586
生きること

C出来る人エキスパート最高！
な時代がきたらいいなぁ

いやとっくに過ぎてるんですが

Cさえあればずっとやっていける
そう思っていた時期が俺にもありました

C言語覚えたら潰しが利くって言ってた奴でてこーい

C++, C#, Objective-C
Perl, PHP, Java...csh(w
オレの知る限りだとこの辺りは文法が近いので乗り換え自由だと思うのだが。

君はどの言語でもFORTRANが書けるんだね

ほとんどの言語はC言語のライブラリの上で動いていて
現状そこら辺を隠蔽した言語はパフォーマンスの壁にぶつかっているので
C言語も多少はやっておいて損はないとおもうけどなぁ・・・

ﾊﾟﾌｫｰﾏﾝｽの壁…ってんなもん意識する機会なんて極わずかだよ…

俺らゲーム製作者には重要な壁だ

多少やるぐらいで埋まる速度差ならおまえが悪い

>>595
ならなぜJavaがNIOというライブラリを追加したのか説明してくれ

Cってプログラミングの基礎だからさー
Cをやってから他の言語をやると割りとすんなり覚えられる
逆に他の言語をやってからCをやってもかなりハードルが高いぞ
だいたいポインタで躓く
プログラマを語るんならCは必須だと思うな
まあもちろんCだけではだめだけどな

C言語の習得ごときにたいそうな誇りを持ってるようだな

ポインタなんて時代遅れ

と、ポインタに挫折した人が申し上げます。

どんな言語でもポインタがわからなきゃ内部でC言語の関数を使うライブラリ呼び出すときに難儀するだろうに・・・

どっちかっつーと関数を作る時に混乱するんじゃね？
呼び出す時なんて&つければいいだけじゃん

>>599
俺はポインタで躓いたあと、
スクリプト言語と浮気しているうちにふっとポインタの使いかたが分かるようになった

浮気者！
　 　 _, ,_ 　ﾊﾟｰﾝ
　（　‘д‘）
　　⊂彡☆))Д´）

>>605
スクラブと言語ってポインタの概念ないじゃん
どうしてふっとわかったのか教えて

>>605
文尾が不完全だぞ
×　分かるようになった
○　分かるようになったつもりだ

>>604
ヒント：キャスト

>>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はあるわけだが。

>>615
68kに(a0)+とか-(a0)とかあるから>>612は書いたんじゃないかと…。

逆だね。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)++;
ダメダメだとわかっていてもつい。

>>634
何を意図しているんだ？

>>635
バイナリのヘッダ解析じゃね？

つーか各方面で不統一だから混乱するだけの話ジャマイカ
俺達人間インディアンだから仕方ないさ

一般ファイルや通信プロトコル、その他特に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であることが多いため命令長が固定できない。
・ｘ86系(Pentium,Athlon,他)
ビッグエンディアン
数値の並びを感覚的に出来る(上の桁を先に書く、という自然の感覚。最初のころはマシン語で直接書いていたことから考えれば･･･)
命令長を固定できる。(こっちの方がエレガント)
・モトローラ系(MC68k,PowerPC)
・SPARC
バイエンディアン(ビッグ/リトル切り替え可能)
・MIPS系(R3000,R5900(PS2のCPU、EEの俗称),R10000)

エンディアン論争はやめーい

one little two little three little endian 〜♪

>>643
ビッグエンディアンかどうかと命令長が固定かどうかは無関係じゃね？

つまり要約するとリトルエンディアンはダメダメで
ビッグエンディアンは素晴らしいって事だよね？

つか、パラメータの類を通信する時に、数値部分をバイナリで送るってプロトコルなんてあるのか？
最近の通信プロトコルは、アスキーテキストが普通だと思ったが・・・。

>>648
いっぱいある。

>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以外は全部糞

>>654
禿堂

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;なんて問題は起こらない

>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となる。

>>672
(´ ,_ゝ｀)

int *p;
は、あくまでint型の型定義であって、*pとか**pとかはpの属性って感じるなあ。

>>672
バカ?

int *p;
int* p;
漏れはどっちでもいいと思うが、一方が「自然」で他方が「不自然」と感じる人もいる。
「不自然」な記法が許されている事が「文法がおかしい」の根拠になるんでないの？

Pascalみたく、変数宣言で識別子と型名の間に区切り文字を入れるかい？

全部参照にすればいいんだよ
int n = new Int(1);

型宣言を根本的に誤解している連中が集う集会があると聞いてやって来ましたが、もうお開きでしたか・・・。

>>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;
の方が自然だと感じる。

>>681
ばかじゃねーの？

int_ptr　が　*　を書かないために使うのなら、
int_ptr* なんて宣言したら意味がなくなるだろと言ってるんだよ。

せめてint_ptrptr くらい書いてくれよと。
その程度のことも読み取れないのにSEになんて・・・・・
あ、ここは死ぬまでコーディングするスレだっけ。

>>682
＞＞型に無関係に関数組めるのがポインタとキャストのいいところなのに
＞これも論点が完全にズレまくってる言葉だよなあ？

int *ip;
long *lp;

ip は intで lpはlongという認識らしいが、変数宣言したスコープ内だけの話だから、
同じ関数に渡せば二つは同一だと言いたかったんだが。

( ﾟдﾟ)ﾎﾟｶｰﾝ

自分が "型名"+'*'　"変数名" に拘るのは、変数でやり取りされている内容、つまりあくまでポインタはアドレスをやりとりするもの
という認識だから。下のレスと合わせてアセンブラの感覚で使っているということでもある。

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
＞ついでに関数のプロトタイプ宣言の意味まで無くしてどうするんだよ。

なんでそんな風に思うか分からないね。


＞値渡しに見えなくもないので

宣言時と使用時はまったく違うわけで、
使用時に勘違いしなければいいわけで。

アドレスの値なんてものを扱えるってのは
もはや低級言語なんだよ。ポインターなんて使わず
リファレンスを使おうぜ。
っま、低級な言語ほど実行速度が速いのは認めてやるぜ！

一回でも自分で言語を設計してみるとＣのうまさが理解できるかも
式（実行文）と宣言とで同じ表現が使えるとか
ポインタ型を別途用意する必要がないとか
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);
}

あ、682 と 693 は別人なんでよろしく

>>696
GCなんて必要ないって。
メモリが歯抜けになるのは、メモリ管理のライブラリがお粗末なのさ。

スタックオーバーフローが検出されないのはOSがしょぼいから。
Windowsならちゃんと例外になるよ。

メモリ管理ってのは
本来アクセスしちゃいけないアドレスに簡単にアクセスできちゃう（ポインタ）ってことでは？

また、スタックチェックはWindowsが行うわけじゃなくて
スタックチェックライブラリがリンクされるかどうかなので
コンパイルオプションしだい。
それに例外はC言語じゃなくてC++言語だし。

メモリ管理というのは、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個の有無で、
極度に読みにくくなるわけでもないだろ？
その程度ならどうでもいいよ。

>>712　自分が良いと思う方を使いなさい
>>713　同意

ただ、プロジェクト内では統一したいよな
オレコーディング規約でもなんでもいいから統一すべし
検索するときに (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);

このスレ面白すぎ。

C言語の場合
int*f;
int* f;
int *f;
は、おなじ？

アセンブラのソースに落して比較すりゃいーじゃん。
つか、それくらいやれ。

わざわざんなことするかバカ

>>733
同じだよ

>>734
文句言うのに2行
答えるのは1行

どちらが楽か自分で考えれよ

いま>>734の髪の毛が一本抜け落ちました

　　　　　　　　　　〜

>>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
とかも

なんて参考にならないスレだここわ！

いえいえ、とても参考になりますよ

嘘ばっかり言われて参考にはならにー

嘘とわかる時点ですでにそれは嘘ではないんだ。
ほんとうの嘘は、誰にもそれが嘘かどうかなんてわからないんだ。
だから嘘をつかない人がいたとしても、その人が本当に嘘をついていないかは

まるっとお見通しだ！

>>715
つ\(int *\*\)

Cのポインタ周りを設計した香具師、ちょっと出てこい。
俺はこれでプログラマになり損ねて今はフリーター。
狂った人生をどうしてくれる。

>>752
呼んだかね？
私が君の質問に答えよう。
ただし！ 1回だけだ。

>>753
彼女ができるようになるにはどうしたらいいの？

>>752
良かったね。

ポインタごときの低いハードルを越えられないようなら、
その先のもっともっと高いハードルの数々は無理でしょう。
早めに軌道修正できて良かったと感謝すべきだろう。

もっと深い事情がありそうだ

>>754
考え方を変えよう、君が彼女になればいい
さあ、今から二丁目に行って来よう

ｳﾎｯ

>>758
ｳﾎｯ じゃないよ。馬鹿だな。いいか、お釜とゲイはぜんっぜん違うんだよ。
お釜は自分が女性でありたいと願うが、ゲイは男として男が好きなんだよ。

何こいつｗ

>>760
「何こいつｗ」 じゃないわよ！ あんたまであたしを馬鹿にする気！？
そうやって人を見下すようだからいつまで経っても独り身なのよ！！

僕には愛するﾐｷﾞｰがいますから。。。

で？　スレタイとは全く違う方向だが？？

そもそもどうでもいいスレ

どうりでsage進行・・・

よし、ミギーが彼女なやつは手を挙げろ！

俺はﾋﾀﾞﾘｰﾇ派なので…

俺はﾐｷﾞｰもﾋﾀﾞﾘｰﾇもどっちでも。でも本命はﾋﾀﾞﾘｰﾇかな

>>768
あたしの他にもいい人がいたのね
その人どこにいるのよ、呪ってやる

お口の恋人ロッテ

こすり付ける派の彼女は誰ですか？

滝真倉さん

奥地の恋人ロッテ？

いくら体が柔らかいったって自分で咥える気になれるか？

よし、>>774を体が硬くてできなかったけど試してみようとしたことあるやつは手を挙げろ！

ﾉｼ

ｻｰ

よ、よし俺以外にも居るな！

ﾉｼ

自演乙

乙かれさま

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
う〜ん、それだと配列の長さが固定になってしまう・・・

>>786
realloc()?

malloc(sizeof(int))の意味がわからん。
int 1個のために一々mallocする理由がわからん。

意図が伝わらないコードは糞コード

>>788
おそらく、ポインタにオフセットをつけ、mallocした領域（変数）を
登録することで可変長配列を実装したいんじゃないかと。

でも、そうするなら mallocした領域（変数）を登録する領域を
可変長にしなければ意味がないんだが。

こういう形で可変長配列を実現してる言語ってあるん？ >>871

失礼。

　× >>871
　○ >>781

calloc
realloc

おまいらセンス無いからダメなんだよ。

>>792
まぁ、普通に考えたらその関数でintの配列として使う領域を確保するよなぁ。

CPUキャッシュやメモリのバースト転送のこと考えたらポインタのポインタで可変長配列、という時点でダメ。
その辺考えたら、普通は、
・malloc()で多めに確保。
・ポインタとオフセットで配列のようにアクセス。
足りなくなったら、
1：代替領域確保→元の領域から代替領域へメモリコピー→元の領域を開放。
2：テンポラリファイル書き出し→realloc()でさらに大き目の領域を再確保→テンポラリファイル再読込み
3：複数のメモリ領域にまたがっていても動くようにする(少々面倒だが現実的）

>>795
ああ。マシンは十分早いのでその辺は考えなくていいです。

プロを煽るならもうちっと高度なことを書いてください。

Ｃにはポインタという型は無いのだが？>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したら、コンストラクタがゴリゴリっと呼ばれてﾜﾛﾀこともある。

用途、環境に合わせて適切なデータ構造やアルゴリズムを選択できない御子様は、
外見だけ華やかな流行の技術でもつまみ食いしてなさいってこった。

>>813
なんだその糞な実装は。

>>809
阿呆ですか？
内部の話始めたら、そもそも new が malloc（ｒｙ

糞みたいなやり取りだな

>>816
当然だが、内部でmalloc呼んでないnewの実装もあるよ。
newがオーバーロード出来るのを忘れてる人は結構いると見た。

巨new

逆にmallocの実装に::operator newを使ってはならないと読んだ記憶がある。

mallocはヒープ領域に
newはフリーストアに割り当てると
山本信雄のVisual C++ 2巻に書いてあったけど
なんのこっちゃ分からんしどうやって実装すればいいか検討つきません。

>>821
VC++ではそうだという話

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ではローカルヒープとグローバルヒープに分かれてた。

昔の名残よのお、、、

>>834
Win3.1までは、じゃね？

>>836
一応、互換性はない。

いまはおなにー

ヒープはプロセスがその都度OSにお伺いをたてて、許可されたら確保されて
手渡されるメモリ領域。土地登記のような厳格な管理下に置かれる。
スタックは予め手渡されているローカルでLIFOなメモリ領域。スタックオーバー
はプロセスの自己責任。再帰処理ではよく注意して想定内で使うしかない。

誰かスタックの話をしてました？
フリーストアってみんな言ってるように見受けられます。

OS管理ではないヒープもあるがな。

OSからは大きなサイズで割り当ててもらって、
Cランタイムライブラリ側で管理するのも手ですよ。

ただそうすると、メモリが無駄になるので・・・。

ちょっと待って、今 >>841 が
>OSからは大きなサイズで割り当ててもらって、
>Cランタイムライブラリ側で管理するのも手ですよ。
ものすごい当たり前の事を言った！

大体のライブラリはそういう実装になってるよな。

mallocなんてその代表格じゃないか？

>>844
そんなあわけはない

ただ闇雲に否定したいだけ？それとも無知？

学生さん

VC6のCランタイムのソースでは、OSに管理させてるな。

といってもWindowsの場合、
Win32APIの呼び出しはシステムコールとは違う。

さらにランタイムライブラリが一枚噛んでいるいるようなもので、
HeapAllocを呼んでも、DLLの中で処理されて戻ってくることもある。

HeapAllocはメモリブロック単位で管理してるんじゃなかったかな。

*記号の流用が許せない
あるときは乗算記号、またあるときはポインタ、またあるときはコメントの一味
しかしてその実体は

参照を忘れてるぞ。

*hoge = xxx

みたいなの。

このスレが、こんなに伸びるとは思わなかった

そりゃそうさ。
普通はポインタを理解しよう、という方向になるのに
このスレはストレートに「おかしい」だからな。
挫折者・落伍者にはオアシスのようなもんさ。

実際のところ、ポインタに躓いている人を観察するとさ、
クソッタレなC言語入門書に書かれているオナニーな用法で、躓いてる。

たとえば、ポインタのポインタ。
型という概念とtypedefの使い方を教えれば、ポインタのポインタは必要なくなる。

もっと革新的な説明の仕方をしてくれてる入門書はないか。
どれもこれもタンスの絵ぱっかでゲロが出そうだ。

タンスの絵とか本の目次とかで理解できなきゃ、
頭を取り替えない限り理解できない

>>850
C++ なんてもっと酷い事になってるからな。
余計な思想まで継承しなくていいっつの。

>>855
メモリにはタンスの引き出しみたいな仕切りは存在しないからなぁ。

カセットテープの場所を指差すもの、というイメージなのだけど、
今の若い人はカセットテープ使わないからわからないか。

方眼紙の升目に数字を書き込んで・・・・というのでも分かりにくいか?

そもそも、アセンブラも未経験、コンピューターの基礎知識、動作原理の知識も無し、
パズルや数学が苦手(理論的思考を不得手とする)なプログラマが多数派になりかねない現状では無理ないかも。

しかもポインタレス言語ﾏﾝｾｰだしな

>>857
Cをまるごと受け継ぐというのがC++の最重要な方針だったわけで。
だからこそC++は成功したんだとStroustrupはD&Eにはっきりと書いている。

それが成功したってことはプログラマがいかに保守的かってことか．．．

て言うか、人は大体保守的だよ。

C との互換性が高ければいい、というものでもないらしい。
つ[Objective-C]

>>857
新しいC++の規格には型の新しい修飾( 右辺値参照だっけ？ )
として && が採用されようとしてるぞ。

また記号の流用かよ orz
aaa<bbb<ccc>> や a = b/*c; で全く懲りてないんだな・・・。

$は未使用だよね。

なんで$を使うのを避けるのかな。

$（笑）

'$'の他にも'@'とか'`'とか。
それぞれダラーや単価記号や逆向きクォートとは限らないので使われないのか?
その割りには'{', '|', '}'もトライグラフで置き換えられるわけだから使ってもいいだろうに。

>>867
$はバックスラッシュでしょ
\と同じコード。
通貨単位だから。
でも、両方出るなあ。

@は単価だし

C++で好きなように演算子つくれ。


＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

　　　　　　　　　　　　　　　　終了

＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊

>>870

>>870
落ち着いて話そう。
まあ、クソスレだしいいか。

&の使いまわしも気に食わないよな
a &= &a && a & &a; とかどうなんのよってのな

&ヽ（｀Д´）ﾉ&

http://ruby.gfd-dennou.org/products/ruby-dcl/ruby-dcl-doc/misc1/node6.html
EBCDICとASCIIの対応 見ると、￥と＄が逆なんだ・・・

特殊文字コード表です
http://www.shikaku-d.com/neko/character_entity.html
ブラウザでは使えるけど、２ｃｈビューワーでは表示できない。

バイナリからデータサイズ毎の先頭アドレスを取り出して扱うってのは
PCの実際の動作に近くていいと思うんだが。
大体、ポインタがなかったら多重リストの実装とかどうするんだ。

記号の多重使用が気に食わない、文法が気に入らない、ポインタ(というか、コンピューターの動作原理)が理解できない。
そういう香具師が見かけポインタの無い高級言語を持ち上げてCを貶めようとしているかのよう。

アスキーで昔(エンターブレインになる前)出てた256倍シリーズのC言語本にはC始める前にアセンブラとPascal習得しろとか書かれてる。

俺、アセンブリ→PL/M→C の順にやったんだが
>記号の多重使用が気に食わない、文法が気に入らない
これは激しくｵﾓﾀ。流石に慣れたが。

>>878
多重起用がうざいってのも
半分はネタで言ってるだけだがな

でももう半分はマジ

そういや、某マシンの某ＯＳ上でしか動作しない言語にゃあ、そのマシン特製キーボードにしかない記号を使って記述する物があったな・・・ポインタの記号だったかなぁ・・・

自然言語に比べたらはるかにマシ

>>881
言語専用文字と言えば APL を思い出す。

>>881
#define

int* p; って解釈するんじゃなかった？
int* を typedef で別名にすれば解りやすい。

int * p;
*p

この両者が似ているのが混乱の元。
どっちも変数の前に*をつけてるだけなのに
一方はポインタ変数であることを意味し、他方はポインタの中身を意味する。
感覚的には変

>>886
おいおい、Ｃ言語の基礎からやり直せｗ
その形式は別にポインタだけじゃないだろ。
そのまんまの記述で型を指定するってだけで・・・

中身はint型になるようなポインタ変数を定義・・・って考えれば何の矛盾も有馬線。

>>888
中身はint型

>>886
int *p;と書いて「*pがint型」になると読めばよいというのがお約束。

>>887
おいおい、宣言子と演算子が同じでキモイって話だろ

C++/CLIの ^ 演算子の方がずっとキモイと思うんだが・・・・

BYTE buf[64];
for(int i = 0; i < 16; i++)
*(int *)&buf[i * 4] = i;

>>893
これやって、ライン１日止めたなぁ・・・

>>894
なんで問題になる？

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回読むだけでコンパイルできるように。

>>912
ヘッダファイルは無くてもいいと？

>>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にも
プロトタイプ情報を含めないとな。
それで実行時に動的チェック、と。

んなアホなことやってられる訳ねーだろ。
自動生成とか言ってる自分本位の馬鹿は死んでくれよ。

プロトタイプを宣言しないってことは、
あるソースをコンパイルしているときに関数呼び出しをみつけたら、
他の全ソースからその関数の定義を見つけだすって事だよね。
ソースファイルが数個程度ならともかく
数千、数万もあるようなプロジェクトではどうなるんだろう？ｗ

どうもならんでしょ。
だってアセンブラには最初からプロトタイプなんてないよ。
もちろんアセンブラにはシグネチャって概念はないけどね。
今のドトネトはもちろんだが、それどころかパスカルにもそんなもんはねえ。

つーかコンパイラじゃなくてリンカの仕事じゃないのそれ。

だな、呼び出し側できっちり型指定すればすむこと。
昔はそうしていたんだし。

>>922
そんなことしなくても cproto っていうコマンドで作れるよ。
少なくとも Linux では動いた。他のOSでは知らないがUNIX系OSなら
動くんじゃないかな。(Windowsは知らない。でも最悪Cygwin使えば
動きそうだな)。

>>927
オブジェクトファイルやライブラリに型情報を含めて持たせて
そこで判定すればいいんじゃないか? あるいはオブジェクト
ファイルとソースの間にもう一つ中間的なファイルを作って
そこに情報を持つか。一度コンパイルすると自動でそれが
作られる。で、まとめてライブラリに付属させる。

まあでも無理にC言語でやる必要はないな。そういう言語
作った方がいいんじゃないかな。

ていうか Java 使ったらどうか?

>>926
>それで実行時に動的チェック、と。
なんでそうなる。
>んなアホなことやってられる訳ねーだろ。
阿呆はお前だ。

>>927
リンカになるべく手を入れなくて済むよう、多くの C++ 実装では
関数名の mangle をやっている。同様にすればよい。

何にせよコンパイラが関数の型チェックするのは無理があるでしょ。

>>926
> ライブラリとか、WindowsだったらDLLにも

あほですか。
そういうものはプロトタイプ宣言したヘッダファイル必須だろうが。

ここで話をしているのは、自分で作った関数について、
プロトタイプ宣言をいちいち書かないといけないのが面倒だから、
自動生成にしたらよい、っていう話でしょうが。

>>934
その程度の話なのか

外部ソースへの参照が有るか無いかだけじゃん。
有る時に規模の小さい日曜プログラムならヘッダー要らないように出来ないかって話だろ？

ないある

プロトタイプ宣言の必要性が分からない馬鹿はプロのプログラマにはなれない

「必要性」ではなくて「重要性」でそ

Java にはそんなものはないわけだが。

Javaは馬鹿のプログラマが使う言語と…。

だから「全部変だよC言語」。
頭の悪い奴は「頭が悪い」それゆえに
自分が頭が悪いと思われることを恐れ「裸の王様」をマンセーする。

で、人間てのは恐ろしいものでそのうち防衛機制が作動しだして
なんだか本当に裸の王様がステキに見えて来る、とw

えっ？ 自己分析？

Ｃと宣言の文法だけを（好きな様に）変えた言語を設計して
それでその言語のコンパイラを書いてみればＣの合理性が分かる

かも知れない

Cより使いやすい言語が出来るかもしれんな。

そうそう。おかしいと思うならおかしくないものを使えばいい。
なければ作れ。

個人的には記号の使いまわしが気に入らないので
新しい言語を開発するにあたり解決すべきポイントは
新しい文字・記号を生み出すということです。
つまり、新しい文字が出来れば全ての問題は解決です。

>>947
それは中国人の発想だな。

そういう考えの結果が積もり積もって、
現在の膨大な量の漢字が生まれてしまった訳だが・・・

結局、歴史的には、記号の数が少ないアルファベット文化が
世界を制してしまった点については、どう思う？

世の中アルファベットぐらいの数の文字しか操れない低脳の方が多いからな。

>そういう考えの結果が積もり積もって、
>現在の膨大な量の漢字が生まれてしまった訳だが・・・

別にそれ自体は悪いことじゃないだろ。
英語だって知らない単語を見せられても意味なんてわかんねぇし。

>結局、歴史的には、記号の数が少ないアルファベット文化が
>世界を制してしまった点については、どう思う？

君の言う「世界を制した」というのが、いったい何を持ってして
「世界を制した」と言ってるのか全然わからないんで、まずは
そこんとこを説明してくれまいか？

あと君はあの悪名高き trigraph についてはどう思う？
記号の数が少ないことによって起きた悲劇なわけだが。

>>948
そういうの論理の飛躍っていうんじゃない？
頭の悪い発想だよw

947じゃなくても普通のプログラマならASCIIの文字セットに不満持ったことがあるでしょ。
たとえば些細なことだけどギリシャ文字の接頭語が使えないから
苦し紛れにuSecとかさ。

>>950
>別にそれ自体は悪いことじゃないだろ。 
本当に悪くなかったらば、中国自身が使用する漢字の量を減らそう、
なんて考えたりはしなかった思うけど？

>そこんとこを説明してくれまいか？ 
一番分かり易いのが、科学全般の発展具合。
漏れは別に「中国の科学と文明」の信奉者ではないが、
それでも科学の黎明期における中国の役割は非常に大きかったと思う。
その大きさと、その後に続く現在の発展具合を見る限り、
漏れでなくとも、誰だって「ナンデ、ソウナルノ？」って気になるだろ？

でも、こんなのは当たり前と言えば、当たり前。
長い間、ご当地で生まれた秀才は皆が皆、科挙の為にタコツボに入って、
数十万・数百万の漢字を必死に覚え込んでいたんだからな。
彼らが生産的な方向に脳みそを使い、かつ円滑な交流がなされていれば、
どんな素晴らしい結果が生まれたのだろうと考えると
悔やんでも悔やみきれない。

>あと君はあの悪名高き trigraph についてはどう思う？ 
>記号の数が少ないことによって起きた悲劇なわけだが。 

スマソ。トライグラフが存在していた事によって起こった
"悲劇"って一体何？

>>952
漢字を覚えるのは簡単。
英単語を覚えるのといっしょで 意味の組み合わせと法則を
それなりに理解してれば、覚えるべきは例外のみで済む。

>>953
ならば、その秘訣とやらを「やねうらお」大先生あたりにでも
教えてやれ。
漢字検定１級を取るのが悲願らしいから。

泣いてよろこぶぞ。

表音文字と表意文字を題材にした比較文化論のスレはここですか？

ハングル文字でも学んどけ
楽だから

Delphiの自動プロトタイプ宣言とはコード補完の事では？

>>948
漢字使ってる人口がどれだけいるか知ってるのか？
世界人口の１／３は漢字を使ってるぞ。

>>952
いや、だからさぁ、なにがどう世界を制したのよ？

あと、おまえ、trigraph を見てなんとも思わんの？
trigraph を知らないだけ？

>>958
>世界人口の１／３は漢字を使ってるぞ。 

世界のプログラマの人口比率でも、
1/3 位は COBOL を使っているだろうな。

>>959
>いや、だからさぁ、なにがどう世界を制したのよ？ 

>>952を読んでないのか、読んでも理解できなかったのか、
最初から理解したくないのか、俺に知るすべは無いが、
これ以上俺に >>959 に納得させる能力はない。
俺の能力不足を許してくれ。

>あと、おまえ、trigraph を見てなんとも思わんの？ 

いや、「思う」とか「思わない」の話じゃなくて、
渡来グラフのために、現場で "悲劇" が起こっているんだろ？

＞1/3 位は COBOL を使っているだろうな。
おれの分野だとひとりも見たことが無い

馬鹿だなお前らは
プロトタイプ宣言なんてやめて、プログラムを宣言部と実現部に分ければいいんだよ
という事でAdaを使いなさい

もうわずらわしいから機械語使おうぜ

>>あと君はあの悪名高き trigraph についてはどう思う？
>>記号の数が少ないことによって起きた悲劇なわけだが。
>
>スマソ。トライグラフが存在していた事によって起こった
>"悲劇"って一体何？

日本語読めないﾊﾞｶﾊｹｰﾝ

>>964
いや結局「悲劇」とやらの内容を一切説明してないんだが。

ま、どうせ「意図せず別の文字に置き換えられて悩んだ」とかだろうが
そりゃ無知だから悩むんであって、悲劇でもなんでもない。

まだわからんのか。小学校の国語からやり直せ

つまり
　trigraphの発明→（なんらかの）悲劇の発生
じゃなくて
　記号の数がすくない→「trigraphの発明」という悲劇
ってことだろ

で、それの何処が悲劇？

>>968
トライグラフ見たことないのかｗｗ

>>969

非常にわかりやすくていいなｗ

>>965
無知なのはお前。m9(^д^) ﾌﾟｯ

結論としては「宣言の仕様はおかしいが、概念がわからない奴はバカ」ってことでよろしいか

　　　　　　　　　　　　　　　　　　　　　）　
　　　　　　　＿ ,,　-ー＝-　、　　　　ヽ　異議なし！！
　　　　　　 ゝ、ニ 二 ＿　ミﾐV,　　　　）
　　　　　　　マ二 ニ､ r'　..,,_ ヽｿ,　　　`ｖ'⌒ヽ／⌒ヽ／　　　　　　 ,. ‐-　.. _
　　　　　　　｀ヽ、 { a`' 　　tij` _!　　　　　　　　　　　　　　　　　　／　　__　　｀` ｰ- 、
　　　　　　　　　|ノゝi　　　　 ,_〈　　　　　　　　　　　　　　　 , ｨ／　　　ゝヽ￣ヽ　ｰ- '
　　　　　　　　 /　　 t　　 -‐ ,'"　　　　　　　　　　　　 _ ／ { {ヽ、_　　　ヽ' ﾉ_,.〉　　
　　　　　　　　/!　　　｀＞､ _/_　-ｧー- ､＿　...　-‐　'　　　 ヽヽ、　｀＞､..ﾉ=┘
　　　　　　 ／j >-‐ ' ´／ /　　 /　　　　／　　　_ノ　　　　　 ＼ `ｰ '!
　　 , -‐ 7´/{⌒|　 ／　_/　　 ｊ　　　　　　　　　　　　　　　　　　＞‐'
　 /　/ /／| 〉‐ｆ／ ＼'　　　　!　　　　　　　　　　　　　 　 , 　' ´
　/　,'　>　.|/　ﾚ　　 ﾟﾉ　　　　|　　　　　　　　　　 ,.. -‐ '"
/　 {　 ヽ　|　 〉　　／＿＿　　ｔ　　　　　,.　-‐ ' ´
　　|　　 ヽ|　/　／　 '　　 `　　ヽ、　 ／
　　|　　　｀!/／　　　　　　　　　　 ／

C言語が悲劇的だったのはその統一されていない仕様ゆえに
IDEによる自動化の恩恵をあまり受けられなかったこと
それゆえに生産性ではJavaやC#の後塵を拝することになる

生産性ではな。

ここ一番の最強プログラムはほぼ例外なくC/C++

最強とか言ってる時点で厨確定

C#が、
実行に必要なすべてをスタティックリンクできて、
EXEファイルが10MBくらいに収まるなら、
大歓迎なんだけどなぁ。

>>975
TurboC とかあったのだが。

PCの場合、スペックが高速大容量化したからCにする
必要性がなくなっただけなんじゃないか? 小さくて
効率のいい実行ファイルを作る必要はないもんな。

それだけでなくPCの場合ユーザの要求が高まってCだけで
作るのは辛い状態になった。

TextSS　のWindowsXP(Professional)64bit化おながいします

もしくは64bitにネイティブ対応したテキスト置換ソフトありますか？

ここは劣化したfjでつね

>>1
それは普通だと思う
配列のはわかめ