[C]ポインタってそんなに難しいの？**[C++]

「ほかの香具師が理解できないようなコーディングはやめるべきだ。」
なんて、もっともらしい理由で注意を受けたんだが、

char *to;
char const *from;

...

while( *to++ = *from++ & 0x7f );　　// これが気にいらんらしい・・・


なんでやねん。

>>540
ポインタ以前の問題

>>540
釣りですか？

char・・・
もしそんなウンコなプログラミングしてるんだったら
ＰＧやめるべきです。

>>542
お前も理解できないんか？
なんでアホのレベルにあわせにゃならんねん。

>>540
俺も気に入らん。

>>540
協調性なさそうだね。

>>540
俺も理解できない。

540は素らしい。

可愛そうだからほっといてあげよう。

>>547
そうね。おそらく話が噛みあわないだろうしな。

>>544-548＝５４２
ﾌﾟﾌﾟﾌﾟ、必死やな。

540さんはｽｰﾊﾟｰﾊｶｰということで、結論が出ますた。540さんありがとう
ございますた。もうお引取り下さって結構ですよ。

>>549
おまえが一番必死そうだよ（ｗ
勘違い君もほどほどにね♪

>>543
「理解できる」とか「理解できない」とかいう話ではない。
またアホかそうでないかという話でもない。
まず、c言語は書いた本人もあとで理解できなくなるほど読み辛い記述が可能だという前提を理解して欲しい。
あなたはそのようなコードをいつでも書いているので、いつでも理解できるだろうが、
過半数のPGはあなたのようなコードを書く習慣は無い。
「書く習慣が無い」ということは、「読み辛い」ということだ。
同一のことをするのにもっと読みやすい記述方法があるだろうに。
あなたの書き方は一番簡潔かもしれないが、可読性が低く、保守性が悪い。

#おれも釣りにしか見えないが、あえて釣られてみる。

>>543
みんな、そう書きたかったんだろうが、
>>「理解できる」とか「理解できない」とかいう話ではない。
ｽｰﾊﾟｰﾊｶｰさんには↑が理解できないと思うのよね。
いや、たぶん、釣りじゃないよ。彼は素だ。

×>>543
○>>552

>>540のコードは、あっさりと理解できますが、他の人はどんなコード書いてるんだ？
笑ってる経験豊かな方々、サンプル書いて、厨な俺に教えてくだされ。

そろそろあの一言が来るのかな？

> いっぱい釣れたなｗ

俺なんて厨すぎて>>540の式が

(*to++ = *from++) & 0x7f
*to++ = (*from++ & 0x7f)

のどっちに評価されるのかすら分らねえよ

>>550
オモロイ

>>552
君は他のアホどもと違って利口そうやな。
誰でも理解できるコードとやらで書き直してみてくれへんか？

>>543
俺はそこまではいってないんだが？

>>552
文字列の終端コード('\0')を代入したらループを抜ける
というのは、Cの文法書に普通に載っている一般的なコードだが？
文法書も読まない香具師に読みづらいとかいわれてもねぇ・・・

ANSIでもK&Rでもいいから、C言語くらい理解しろよ？

・・・と、ついでに俺も煽ってみる(w

ｽｰﾊﾟｰﾊｶｰさんいらっしゃい。他にはどんなコードを書いて
るんですか？僕らﾊﾟﾝﾋﾟｰにすばらしくもｴﾚｶﾞｿﾄなコードを
授けてください。

>>561
文法書嫁

いっぱい釣れたなｗ

540本人が出てきたので終了です。
関西弁変じゃなかった？ｗ

釣れた言う奴は負け犬

>>560
スーパーハッカーさんいらっしゃい♪

凡人にはあなたのコーディングは神々しすぎて、クラクラきちゃうのです。
凡人はほっといて、スパーハッカーなコーディングを続けてくださいね（ハァト

あっ。
私は凡人なので、ほっといてください。

誰が言ったのか分からんけどな

>>560
なんと540と543は別人だったか。
いにしえの（今はstrcpy使うからね）文字列複写コードだったとは。
教えてくれ。
while( *to++ = *from++ );
ではなぜいけないんだ。

ｽｰﾊﾟｰﾊｶｰさんえ：これからも、いろいろなｽｰﾊﾟｰﾃｸを披露して、
このｽﾚｯﾄﾞに巣食っている愚民どもを導いてやってくださいあし。

>>568
パッと見、分かりづれぇだろ。

>>568
while( *to++ = *from++ ) 書くくらいならstrcpy使う罠。
7bitに落とす必要があったのさ。

>>570
あれが読みづらいんだとすると、
パッと見分かり易いコードとやらを書いていただけると
非常にありがたいのだが？

>>568
それでOKなんだよ。でもねぇ、世の中馬鹿ばっかりだからね。
K&R程度のことも理解できない奴も多いし、誰とは言わんが理解
できたからって早速実務で使って自慢しに来るアホもいるし。
自分でメンテまでやるんならそういうコード書いても無問題
なんだが、メンテやる奴がアホだったりすると、いちいち聞きに
きたりしてウザいじゃん？それにいつまでも昔のコードを全部
自分でメンテし続けるのも嫌だしさ。
だからC言語をロクに理解してない低能でも読めばわかるように
書いておくのさ。そうすれば、新人あたりに「勉強のため」と
称してメンテを押し付けることもできるだろ？そして自分では
もっと楽しい仕事が始めるというわけさ。

>>572
と、ポインタの使い方も理解していない馬鹿が申しております(w

>>571
スーパーハッカー先生！
0x80の立場はどうなるのでしょうか！

>>571

>>570では分かりづらいとは書いたが読みづらいとは書いてないよ。

>7bitに落とす必要があったのさ。
while( *to++ = *from++ ) のコードだけからはその意図が伝わらないだろうがｳﾞｫｹ

>>540 >>571
strcpyしてから、7bitに落とすという書き方の方がbetterだと思う。

>>540のコードでコメントとして "//7bitに落とす”
を書きさえすればそれでいいじゃん

>>574
ハァ？0x80なんてどこで使うんだよ。
7bitに落とす場合、そんなもん出てきた時点で
終了コード扱いで問題ないだろ。
・・・つか、おまいはどうしてほしいんだ？

>>575
どこから電波を受信してるんだ？
もう一度>>540よんでみろ。

>>576
やってみますた。
なんか、無駄じゃね？

char *to;
char const *from;

strcpy(to,from);
while( *to++ &= 0x7f );

>>577
そうだよｳﾞｫｹ

おいおいお前ら（ｗ
結局>>540を笑ってたお前らが、一番間抜け。
まもともなコードかける奴なんていないじゃん。
特に>>568は馬鹿。

>>578
576=552=568
そっちの方がよっぽど良いよ。
も一度>>552を読めばなぜ良いかがわかると思うけど。
>>578の方が長くて（２行）かつ遅いよ。
でも>>578の方が良い。

>>581
もちろん、会社では while( *to++ &= 0x7f ); も
読みづらいと文句を言われた訳だが・・・(w
自分が理解できない文法を認めない香具師多すぎ。

一応言っておくと、576のアプローチは最悪。
それをやるくらいなら、for文に展開して保守者が読めるようにする努力をしろ。
最適化がかかりづらいコードを書くのは、客に対して失礼だろ。

一応、>>540の趣旨は
「なんでこんなコードが理解できねー香具師が大半を占めてるんだよ」
であって、あのコードのすばらしさ(w を説く予定なんてなかったんだが(^^;

>>580 俺は>>540を笑った覚えは無いぞ

バカ対策としてオブジェクト指向否定派に喝を入れよう。
こいつらがバグの温床になっている。
しっかりとオブジェクト指向教育でしごいてやらねばならん！

ﾋﾞｼｯ! ﾊﾞｼｯ!

とくにCOBOLerやVB厨、C厨にはしっかり教育してやらねばならん！！！！
しかしC++厨の大半はオブジェクト指向を理解せず使いこなしていない、化けの皮を
はがすとただのC厨程度のレベルの低脳しかいないケースが多すぎる。
C++ができるといえば周りが高く評価されると思い込んで背伸びをしているC厨が多すぎる。
こいつらこそ抵抗勢力だ！　こいつらがもっともタチが悪い！

いまこそ

　　C++厨に

　　　　喝　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　　ー　ー　！！！！！！！

>>584
ｳｻﾞｲ

>>578
スパーハッカーな先生！
では0x81はなぜ落とさないのでしょうか？
教えてちょんまげ！

>>586
お前は7bitコードというものを理解してから出直して来い。

>>586
シッー！

核心を付くようなことは言わないの！！
スパーバッカーさんの機嫌を損ねるじゃないかｗ

ってか、ビット落としで0x80のこと考慮しない香具師に
プログラム作ってほしくないな。
そもそも、ビット落としで終端判定が'\0'っていうお馬鹿ぶりが
なんともいえずスパーバッカーですね♪

>>588
とまあ、Cの言語仕様すら理解してない馬鹿もいるわけだが

言語仕様を理解出来てるおまいらが羨ましいよ

>>582
>それをやるくらいなら、for文に展開して保守者が読めるようにする努力をしろ。
あのコードを書いた人間の発言とは思えないな。両極端だ。
「576のアプローチ」は中庸だと思うのだが、なぜ最悪だと思うのか。

>最適化がかかりづらいコードを書くのは、客に対して失礼だろ。
コンパイラの最適化のことだな。なぜ失礼だと思うのか。
俺は全然そう思わない。だいたい必要でない限り最適化なぞしない。

＞「なんでこんなコードが理解できねー香具師が大半を占めてるんだよ」
それが現実だ。おれも最初は理解できなかった。
アプリでデータをハンドリングする単位が1byteであるような局面が
極端に少なくなっているという原因／背景はあるが。

>>586==588
粘着ウザイ。勝手に仕様を作り出してホザクナ。
それよりはやく、おまえなりの>>540のコード書いてみろよ。
っていうか、おまえ、プログラム書けないんだろ？

夜中だってのに盛り上がってるよなぁ・・・(^^;

>>591
プログラムの「品質」は理解しているか？
リソースを有効に活用するのも品質条件の一つだ。
メモリやCPUなどのリソースも顧客のコストに跳ね返ってくるんだよ。

まず顧客のことを考えろ。
次に保守のことを考えろ。
次に生産コストを考えろ。
・・・基本だろ？

>>591
＞＞「なんでこんなコードが理解できねー香具師が大半を占めてるんだよ」
＞それが現実だ。おれも最初は理解できなかった。

そう素直に書かれると、仕方がないな。
でも、教科書に載せるプログラムじゃなく、仕事で使うプログラムなのになぁ。
ＯＳ上で動くプログラム組んでる奴と、組み込みやってる奴じゃ思考が違うのかな。

>>540
あっさりと理解できるヤシだってたくさんいるんだ、まぁがんがれや。

簡単だよ

うぅ〜ん。
どうしても疑問なんだが。
7bitコードにしたいんだよね？
0x81 -> 0x01
0x82 -> 0x02
0x83 -> 0x83
のように。

でもって、終端コードは0x00なんだよね？
ここで、0x80も終端コードにするって考えかたが
どうしても理解できないんだが。
0x80が出た時点で後続は変換されないのか？
中途半端な仕様だな。

>>596
聞いてもない仕様にケチつけるお前も変わってるな。
仕様とコードが食い違ってたらケチつけろよ。
いまのところ、あのコードで仕様を満たしているかどうかは540のみが知るところだ。
0x80は終端でよいのかも知れないし、バグかもしれない。
なぜお前が悩む？

「品質」がでたか。
俺はアプリ屋だが、あなたは違うことが類推できる。
555と同じ組み込み屋さんかな。
品質の各種特性に対する優先順位が全然違う。

最初に生産コスト
次に保守コスト
等々があって、
資源のコストの優先順位は最下位に近い。

おれの考えるアプリ屋の品質に対する「基本」はこうなんだ。
資源のコストが再優先なら、あなたのコードは最適だ。
保守コストが犠牲になっている（かもしれない）が。

>>598
えらく自分本位な開発だな(w
学生かい？
ソフトウェアサイクルにかかるコストは理解しろよ。

「たかだか数行のソースの書き方がスタイルに合わんからといって、
客のリソースを無駄遣いする」
ということに疑問を抱かない姿勢もどうかと思うし、
生産コストが保守より優先されている時点で論外。

・・・・つか、保守がおろそかでいいのなら、
>>540のコードに文句があるのはどういう了見だよ(w

>>599
何年この業界で飯を食っているかを書くと、
ジジイと呼ぶ奴が出てきて不愉快なので書かない。
アプリの世界では、客は資源を有効に使っているかどうかなんて気にしない。
今ある（もしくは導入予定の）コンピュータで、アプリを使用して得られる効果が、
アプリを導入するコストに充分に引き合うかどうかが関心の全てだ。

「自分本位」なのではない。アプリ開発は、
生産コストや保守コストと、資源のコストのトレードオフを判断するときに、
ほとんどの場合（遅くて使用性が損なわれるといった場合以外）、
前者が優先されるという世界であるというだけのことだ。

「姿勢がどうかと思う」とか「論外」とか思うのは勝手だが、
「自分の仕事だけがプログラミング／ソフト開発の全てではない」と考えて欲しい。

#最後の2行は意味がわからない

#あなたは、自分のパソコンのcpu稼働率が100%でないと嫌なのか？

おまいら取り敢えず落ち着け。
問題はあのコードが理解できるか出来ないかであって、姿勢の話しではない。
結局の所それは個人レベルの話しだろ。

>>601
はぁ？

そもそもが
>「ほかの香具師が理解できないようなコーディングはやめるべきだ。」
なんだろ？

でもって、このスレでも「わかりづらい」って言ってる奴が
何人か居るようだぞ。
また、終端コードの問題も本当にこれでいいのか？って
コーディング見ると悩まなければならない。

よって、注意は妥当だろ。

おこちゃまプログラムじゃなくて、職業プログラムは
万民がわかるように作らないとダメなんだよ。
リソースの話だって、あの例は最適ではない:-)

じゃぁ辞める。
もうそれでいいじゃないかヽ(´ー｀)ノ

while ( (c = *from++) != 0 ){
*to++ = c & 0x7f;
}
だったら文句ないのか？

>>602
言語を理解していない奴にあわせてもなぁ

ポインタはアドレスを操作する奴。

---------------------終了------------------------------

>>602
>万民がわかるように作らないとダメなんだよ。
莫迦にレベル合わせてたらまともなコードなんて書けませんよ。
まあ >>540 のコードが見辛い、ってのは莫迦だとは思いませんが、
判らないってのは問題でしょうね。

さらに初心者向け
while(*from='\0'){
　*to=*from&0x7f;
　to++;
　from++;
}

最終的にはポインタじゃなくて配(ry

>>604、>>608
仕様が変化してる。

まぁ、このように勘違いし易いコードだってことだ。

540さんえ。 while( *to++ = *from++ & 0x7f );に続くｽｰﾊﾟｰﾃｸは
まだでつか？

いっぱい釣れたなｗ

>>611
540の間違いか？

>>609
仕様なんて「(7bitで)文字列をコピーする」だろ？
話にまで出ているのに>>604、>>608のようなコードを書くのは、
「文字列のコピー処理すらろくにかけない香具師だ」としか思えんが・・・
こんなド素人は相手するだけ無駄。

そういう意味では、>>607に禿同。

>>612
おれじゃないよ？

バカハゲ対策としてオブジェクト指向否定派に喝を入れよう。
こいつらがバグの温床になっている。
しっかりとオブジェクト指向教育、UP教育、XP教育でしごいてやらねばならん！

ﾋﾞｼｯ! ﾊﾞｼｯ! ﾌﾞｼｭｯ!

とくにCOBOLerやVB厨、C厨にはしっかり教育してやらねばならん！！！！
しかしC++厨の大半はオブジェクト指向を理解せず使いこなしていない、化けの皮を
はがすとただのC厨程度のレベルの低脳しかいないケースが多すぎる。
C++ができるといえば周りが高く評価されると思い込んで背伸びをしているC厨が多すぎる。
こいつらこそ抵抗勢力だ！　こいつらがもっともタチが悪い！

いまこそ

　　C++厨に

　　　　喝　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　ー　　ー　ー　！！！！！！！

540が、チーム開発に向いていないリアル厨房だというのは良くわかった。

>>614
あたまおかしいのとちゃう？

ｵｫｲｪｴｪ！
今こそスパゲティコード撲滅委員会を発足させよう！

char *******************************p;

>>618
そんなもんつかえんの？
いっそのこと、クラス使ってコンポジットパターン使ったほうがよくない？

>>619
　ネタにマジレスするな。
　ついでにこんなとこまで来るなデザパタ厨め。

デザインパターン知らない奴はC++プログラマとは認めず

>>621
ちょっと待て。いいかげんなこと言うな。
デザインパターンという言葉はC++より新しいぞ

>>615 >>620
似非プログラマはここに来るなよ。うぜーから。

>>613
whileは条件判定してから、処理を実行するという先入観を持たせる。
>>540でwhileを使ったから、その先入観で>>604、>>608は条件判定してから
コピーをするというコードを書いてしまった。

こういうことは考えないのかい？
自分が勘違いしない、より考え易いコードを書くために
こういうことを考えるけど。

>>624
はあ？
「whileは条件判定してから、処理を実行するという先入観を持たせる。」
なにいってんの？
文法書くらい読んでから出直して来い。

>>622
しかしデザインパターンの手法は
デザインパターンが登場する前からすでに存在していた。
よってデザインパターンすら使いこなせない厨はC++プログラマとは名乗らせる
べきではない。

そういう馬鹿どもは>>614の言うとおり背伸びをしているただのC厨に過ぎないのだ。

> しかしデザインパターンの手法は
> デザインパターンが登場する前からすでに存在していた。
日本語意味不明でーす。
登場と存在の違いを明確に示してくださーい。
まさか「C++が登場する前から〜」とでも言いたかったのか？

>>627
お前日本語も理解できんのか？
ﾌﾟｯ

>>627をみると
さすがC++厨はプライドが高いな。
なんといっても自称「最強」だからなw

デザインパターンってのは「設計の雛型」のことだろ。
そんなものプログラミングの歴史が始まってからずっと存在しているぞ。
それに、名前を付けて、整理し、まとめたのが1994年の同名の本の功績だと思っているんだが。
「デザインパターンすら使いこなせない厨はXXXプログラマとは名乗らせるべきではない。」って
XXXのところには任意の言語名が入るんじゃないか。

そういうことだ。
任意のオブジェクト指向だ。

>>625
>>624が言いたいのは while ( 式 ) { 文 } の中で
まず式が評価される、ということでしょ。
>>540ではコピーした結果を評価してるのに
>>640、>>608は評価してからコピーしてる。
つか、>>608はそもそも条件が間違ってるけど。

>>596
>0x80が出た時点で後続は変換されないのか？
0x80があってもOKなバージョン

while (*to++ = *from & 0x7f, *from++);

これで>>604や>>608と等価だ。

あごめん。等価じゃなかった…

改めて等価なバージョン

while (*from? *to++ = *from++ & 0x7f, 1: 0);

>>635
すばらしい。540なんてメじゃありませんな。あなたに比べれば
540などケの生えてない消防レベルですよ。540など、K&Rの練習
問題がやっとできて喜んでるレベルのｶｽですな。635さんこそ、
真のｽｰﾊﾟｰﾊｶｰですね。

>>540のコードは
「反復と終了条件判定」「二つのポインタのインクリメント」「bit（マスク）演算」「代入」
の四種の演算を一行でおこなっているわけだ。まあ>>635も同様だな。
>>594を読んで、あの種のコードを普通に書いている開発も世の中には存在するということがわかったよ。
でも「あの種のコードを通常書かない香具師」の割合は増えてきているのではないか。
だからこそ「ほかの香具師が理解できないようなコーディングはやめるべきだ。」という
>>540の先頭行に書いてある指摘があったのだろう。おれも含めてほかの香具師は確かに（すぐには）理解できないんだ。
しかしその理解できない香具師に「馬鹿」とか「ド素人」と言うのは、正しい言動とは思えない。

>>636 もうやめてあげなよ。

やっぱ配列にするのが一番分かり易いよな。

>>638
メモリ領域を静的に確保して問題の無い仕様ならね。

じゃなくて、配列としてアクセスするってこと。

>>635
それだとfromの'\0'は代入されない。
さらに0x80が7ビットに落として代入された時点で
Cの文字列としては、toはそこが終端でしょ。

>>635の方法で行くと、toにコピーされたデータの
どこまでがfromから渡された物か分からない。

>>640　理解しました。御無礼。

>>641
>>635はあくまでも>>604と等価なものを書いたんだって。

>>635が期待通りに動くかは、調べないとわからなかった。
三項演算子でより低い優先順位の演算子がどうなるかまでは
知らなかった。

「0x80が終了でいいのか？」と疑問に思ってるﾔｼへ

7bit文字ｺｰﾄﾞにﾊﾟﾘﾃｨﾋﾞｯﾄを付加して8bitで送信してくる制御機器があるのよ
それを受信する側はﾊｰﾄﾞｳｪｱの機能でﾊﾟﾘﾃｨｴﾗｰを検出できるならば
単純にﾋﾞｯﾄを落とす操作だけでよいことになる。
偶数ﾊﾟﾘﾃｨの場合は0x00、奇数ﾊﾟﾘﾃｨの場合は0x80がそれぞれ終了ｺｰﾄﾞになるので
>>540はEVEN、ODD両方に対応していると言える

そういう仕様なのかどうかは540にしか分からんと言われてるんだと思うが。
そーかもしれんし、そーでないかもしれん。
540はその意識だったのかもしれんし、書いた時点でｱﾌｫやっただけかもしれん。

>>644
絶句。
文字列終端としてのnulではなく終了コード？

それが本当なら、とても危険なコードだ。
おれの感覚だと、0x00と0x80の双方と比較するべきだと思うんだがなあ。

>>646
ごめんね、それはうそ。
終端ね、終端

>>637
「理解できない」と「わざわざ」書いたり発言したりする香具師は、「バカ」か「ド素人」だろう。

ああ、まだやってたのか。
まる２日たったような。
でさあ、結局 >>540 が仕様的に正しいとして、どんなコード書くのが理想的だと思う？

>>649
すごいよなぁ、10レス燃料のつもりで書いたんだが、
まさか100越えるとは・・・・(^^;
つか、540みたいなしょうもないコードで大騒(ry

>>649
「理想的」というのは「そのプログラムがどのような品質特性を持つべきか」であると思う。

効率（=資源コスト）が最優先で保守性は二の次である場合には>>540のコードだ。
このコードより速いコードはちょっと思いつかない。おれの能力の限界かもしれないが。（アセンブラは別にして）
#このコードは保守性が犠牲になっているという現実が気に入らない／認めたくない香具師もいるようだ。
#cを扱える人間なら誰でもこのコードを容易に保守出来るべきであるとまで思っているかもしれない。

逆に、保守性が最優先で効率が二の次である場合は、
>>608のような（「ような」に注意）コードだ。
俺が書く場合は、strcpyしてからfor文だが。
#この書き方を全面否定する香具師もいるのは十分承知だ。

>>651
なんか、しょうもない事にこだわるなぁ・・・(^^;
どこが「保守性が犠牲になっているという現実」なんだか・・・

>>649の求めている
「お前が理想的だと思えようなコード」を提示できない時点で ただの馬鹿。
一度 お前の言うようにfor文で実装してみろ。どうせ読みづらいから(w

>>651
＞#cを扱える人間なら誰でもこのコードを容易に保守出来るべきであるとまで思っているかもしれない。
「Cプログラマ」に金を払う方からしてみれば、その通りです。
できないなら「C使えます」と言わないで下さい。

>>652
別に拘ってなどいない。暇なだけだ。
>>582 で
「なんでこんなコードが理解できねー香具師が大半を占めてるんだよ」
というあなたが自分で認めた現実が、
「保守性が犠牲になっているという現実」
を意味しているんだ。

ただ単に以下だ
strcpy( to, from );
for ( ; *to ; *to++ )
　*to &= 0x7f;

やっとマ板らしくなってきな。

間違った
strcpy( to, from );
for ( ; *to ; to++ )
　*to &= 0x7f;

>>654
それなら、

for ( ; *from ; from++ )
　*to = *from & 0x7f;
*to = '\0';

とか

do{
　char c = *from ;
　*to = c & 0x7f;
　to++,from++;
}while( c );

とか 書いてるほうがましじゃねーか？

つか、>>654のソースで、
いったいどれだけの香具師が理解できると思ってるんだ？

>>540,>>578 のコードが理解できない香具師の大半は
C言語での文字列とポインタを理解していないのがほとんど。
for(;*to;to++) で
「文字列の終わりまで繰り返す」とは読んでくれねーんだよ(T_T)

>>655
深入りしすぎるとム板っぽくなるよ。

>>657
すまん、to++ が漏れてた(w

>>654-657
一番良いコードはこれ↓だ！
----
strcpy_with_cut_7bit(to, from);
----

void strcpy_with_cut_7bit(char *to, const char *from)
{
while (*to++ = *from++ & 0x7f);
}

お前らアホか。仕様を満たして、かつ、無駄な処理がないのなら、
別にどう書いたって良いだろ。開発チームのメンバのレベルに合った
コーディングをすれば良いだけだ。その上で遅かったら最適化を
行えば良い。
540の職場は、K&Rも理解できて無い奴が多いんだろ。チームリーダー
として見たら、他のメンバが保守できんコードを書かれても困るからな。
こんなとこでぶつぶつ言う前に、メンバのレベルを上げるか、さっさと
転職しろ。>540

複数人のプロジェクトのときは
do {
　c = from[i] & 0x7f;
　to[i] = c;
　i++;
} while (c != '\0');

一人のときは
i = 0;
while (1) {
　to[i] = from[i] & 0x7f;
　if (to[i] == '\0') break;
　i++: // 一回少ない
}

>>654のようには書かないなぁ。

>>657
「可読性」だけに話を絞って検討するにしても、「どちらががましか」も見解がちがう。「どれが一番読みやすい？コンテスト」をやるつもりもないしね。

>for(;*to;to++) で
>「文字列の終わりまで繰り返す」とは読んでくれねーんだよ(T_T)
あなたの悲しみはわかった。
なぜわかるかというと、私も同様な立場になったことが何度もあるからだ。
>>662　の提案を採択するのもないではないが、そんなことをしなくても

「ほかの香具師が理解できないようなコーディングはやめるべきだ。」と指摘した奴（リーダかな）の言う通りに書きなおしてやる。

というのが現実的な対処かと思う。実務でもそうしたのではないか。

#私の場合は、「関数ポインタの配列を作って文句を言われた」のが一番印象深い。
##なるべく「スレのテーマに関連する話題をだす」という努力はしなくてもいいのかな。

>関数ポインタの配列
どんな用途のプログラムだったんだろう・・・。

現実的な対処
↓
いつのまにか当然のことだと思い込む
↓
部下にも同じことを強制する
↓
ついには全社的な禁忌に
↓
分厚いコーディング規約書ができる

とか。

「分かりにくいから直して。」じゃなくて
「分からないから直して。」って言われたんなら
ご愁傷様。早めに転職しましょう。
(部下ならちゃんと教育しましょう。)

>>665
連続した整数をキーにして処理を分岐する場合、ふつうに使いますよ。
// キーが不連続だったり、文字列だったりした場合は
// 「キーと関数ポインタを含む構造体の配列」になります。

動的に変化しないのであれば、頑張って switch で処理する
事も可能ですけど。

>>664
お互い色々苦労してるようで(w

# 可読性については好みの問題もあるだろうが、
# 可読性が変わらなければ、実行速度を考えろって事がいいたいだけ。:-)

関数ポインタの配列ねぇ。
確かに知らん香具師多いよな。
おれも最近、引数を関数のポインタにしただけで・・・(T_T)


数年前の話になるが、
関数ポインタの配列を返す関数なんてのを作ったら、
説明するのが一苦労だった思い出が・・・

たまたまターゲットが組み込み系のシリーズで、
ターゲットの機種によって割り込みハンドラを
選択するようなやつをCで実装してたんだが、
よめねー香具師多すぎ。
俺も若造だったので、文句すらいえず、
typedefなくしたバージョンとか色々用意して苦労したよ。

>>663
無限ループからbreakで抜けるのって、嫌がられないか？
だから一人のときにしか書かないのかも知れんが。

「本当に終わるのか分からないじゃないか」とか言われるんだよな…
じゃあ、お前は普通に条件が書いてある場合は終わるのかどうか
見てすぐ分かるのかと小一時間…

>>669
昔、構造化がどうとか言われたような言われなかったような…
そういう話を聞いたことあるだけかも。

うちはアルバイト使うんで、マイナーな書き方は自制するつもり。

>>671
ああ、
構造化＝goto(とそれに類するbreak, continue, 関数の終わり以外のreturn)を使わないこと
とか勘違いした香具師が広めたやつか。

昔ながらの常套手段を
「可読性が・・・」とか言うな

昔を知らないからだろ。
知ってる奴に教わったことも無いし、そういう本も読まない、そういう奴。

>>674
そんな奴に可読性とかいわれたくないよな(w

>>674
そして、口伝で部下や後輩にその教えが受け継がれる。
もちろん、その部下や後輩が、聞いた以上に深く勉強しようとはしない。
仕事は忙しいし、自分の自由な時間は自分のため(＝遊ぶため)に使いたいからな！

>>676
今は「口伝も」あるのか。羨ましい。
昔はネットなんぞ無かったし、本も貧弱（K&Rだけ）。
私は他人のソースをかっぱらって（こぴって）、覚えたもんだが。

>>677
すまん。発作的に昔話をしてしまった。
失礼しました。

==576
>>673
わかっていないなあ。視野が狭い。
「あなたが知っている／知らない／読める／読めない」とか
「私が知っている／知らない／読める／読めない」という話ではないんだよ。

「文字列の終端はnulである」というルールを知っている（教えた）にもかかわらず、
while ( *to++ = *from++ )　が文字列複写であることや、
for(;*to;to++) が「文字列の終わりまで繰り返す」という反復であること
を、「知らない」とか「(すぐには)理解できない」って香具師が増えてきているってことなんだよ。
このような状況下で、
「そういう奴らに保守をさせなけなればならない場合、（当然、教育が本道なのだが）
コードレベルで工夫するとしたら、奴らが保守が可能となるコードはどうなんだろう」
って話題だったんだけど。

# for(;*to;to++) を
# for ( ; *to==0x00; to++ )　や for ( ; *to=='\0'; to++ ) にしても駄目かな。

>「そういう奴らに保守をさせなけなればならない場合、（当然、教育が本道なのだが）
>コードレベルで工夫するとしたら、奴らが保守が可能となるコードはどうなんだろう」
そんな下らんことしてないで、とっとと教育しろや。

↑だと、使えない奴は使えないまま。んで、OJTしてでも教育してやろうという
奴がいないどころか、そもそも教育できる奴すらいない、という悪循環だな。

『もしかしらた将来そういう馬鹿に保守させないといけないかもしれないから、
「むつかしめ」なコードを書くと余計手間がかかるかもしれない』、
などと想像してる暇があったら、もっと未来の、全体的なことも想像してみたら？

==576
>>680
>『もしかし 〜　手間がかかるかもしれない』
そう思ったのは>>540のコードレビュー担当者だね。
それを雑談ネタにしたのは私だけど。

>もっと未来の、全体的なことも想像してみたら？
それをしなければならないのは、PGではない。ロードマップを描くのは経営者の仕事だよ。
自分が将来どうなるかは興味があるが、所属している組織の将来には興味は無いんだ。
#「教育の問題」に話題を限定しても、私の判断は「先行投資が必要」なんだけど、
#それを決裁する立場にいるわけでもないしね。

>それをしなければならないのは、PGではない。ロードマップを描くのは経営者の仕事だよ。
うーむ。
こうやってだめ技術者が量産されていくのか…
経営者がだめなら技術者もだめって典型だな。

>#「教育の問題」に話題を限定しても、私の判断は「先行投資が必要」なんだけど、
コード書くのに無駄な労力かける前に、やることあるだろ？

> もっと未来の、全体的なことも想像してみたら？

>　やることあるだろ？

糞の役にも立たない曖昧な説教ﾜﾗﾀ

>>682
教えられる立場にある人間が >>683 みたいなのだったら
放置していいですよね?

まぁ、そんなこんなで>>666の
>いつのまにか当然のことだと思い込む
>↓
>部下にも同じことを強制する
という連鎖が続いていくわけなんだが。

>>684 現場では報知プレイはNGだ。デスマ転落するリスクが発生する。
>>680 と >>682 も「曖昧な説教」といわれないようなレスをしなきゃ。
でも「従業員全員が経営者意識を持って云々」とかは言うなよ。

わかったフリをして生きてる自尊心肥大症な奴って、よく>>682みたいに
勝手に飛躍してなんか悟ったり、「思考してますよというポーズ」以外に
内容のないこと言って他人を見下すよな。

へぇ。
「偉そうに見える」ことが書いてあると「見下してる」ということにしおきたい。
痛いところをつかれると「曖昧な内容」ということにしておいて、みなかったことにする。

面白いな。

もはやポインタとは何の関係も無いな。。。

>>688
ええ、そう思い込もうと頑張ってしまうあなたは末期症状です。

>>690
ﾏﾈしたってだめだよ。

>>1-691
goto hell;

>>692
Cでgotoを使わない理由を考察するスレ
http://pc.2ch.net/test/read.cgi/prog/1053627318/

ようするに
K&R期のCプログラマか、その影響を直接受けた人達と
最近の明示する事がいい事と教えられた人達で意見が合わないだけでしょ。

俺は後者なんで、前者の人は
> 知ってる奴に教わったことも無いし、そういう本も読まない、そういう奴。
なんて言わないで欲しいな。
明示する文化ってのは最近の そういう本 を読んだ結果の新しい文化なんだって理解してほしい。

ちなみに前者の文化は
余計なものを書かない文化だと思ってる。
端末の一行の文字数も少なかっただろうし、
記憶装置の容量も省きたかっただろうし、
最適化も甘かったんだろうし、
だからシンプルがいいって事になってた時代と文化があったんだと。
今はそれよりも、わかりやすい方がいいっていう文化が主流になりつつある、と。

それだけの事だと思う。

>>695
いつの世も、シンプルが一番だろ。
複雑なコードはバグの盛り込みも多い。

while( *to++ = *from++) ってのは、C言語で一番有名な"慣用句"だ。
一種の「デザインパターン」だろ。
今の文化にこそ必要なことだと思うが？

どうしてベテランが、一定のコーディングスタイルに
こだわるのか考えてみろ。

一度くらい、コーディングスタイルブックや
デザインパターンの理論について書かれている書物を嫁。

>どうしてベテランが、一定のコーディングスタイルに
>こだわるのか考えてみろ。
単純に楽だからでしょ。スタイルに乗っかってる方が疲れない。プロとしては
正しい姿勢だと思う。

わかりづらいといえば、俺には下記のコードが何をしているのサパリわからんんだが。
a = ((a & 0xAAAA) >> 1) + (a & 0x5555);
a = ((a & 0xCCCC) >> 2) + (a & 0x3333);
a = ((a & 0xF0F0) >> 4) + (a & 0x0F0F);
a = ((a & 0xFF00) >> 8) + (a & 0x00FF);

最適化汁。
つか、ぽいんたじゃねーよ

　　 ／￣￣'' -、
　 （　　　 ／ )　ヽ 　ジャーパネットー ジャパネットー♪ 夢のジャパネットたかたー♪
　　i　r-,,,, ／,,,,　）
　（ >|　●　 ●//
　 `‐|　　 Ｕ　 /ノ　 　やった！！高田社長様が>>700ｇｅｔだ！！
　　　＼　━ /
　　 ((Οっ V> 　　　　　　オラてめえら！！ウチの商品を買えウンコども！
　　　 ＼　　'oヽ
　　　　　|,,,,,,∧|
　　　　 /　 ∧ ＼　　　　　>>701　 今さらCPUが1GHz以下の低速パソコンなんか使ってんじゃねーよ(プ
　　　／　／　ヽ　ヽ　　　　>>702　 15インチのＣＲＴなんか使ってると目を悪くするぜ(プ
　　　ト-<　　　 |_／'.'.┐　 >>703　 超低画質プリンタで来年の年賀状作成か。おめでてーな(プ
.　　　　　　　　　　　　　　　>>704　 50万画素以下のカメラでプロ気取りか、おめでてーな(プ
.　　　　　　　　　　　　　　　>>705　 親戚の前で恥をかく前に電子辞書を使って日本語覚えろよ(プ
.　　　　　　　　　　　　　　　>>706　 今やMP3の時代なのに、カセットテープなんて使うなよ(プ
.　　　　　　　　　　　　　　　>>707　 VHSより時代はDVD・HDDレコーダーだよ、３倍ヲタク君（プ
.　　　　　　　　　　　　　　　>>708　 今さら８ミリビデオカメラなんて使うなよ。今やDVかDVDの時代だぜ(プ
.　　　　　　　　　　　　　　　>>709以降は金利手数料は自分で負担しとけ(プ

こうかな？

define MASK_PATTERN 0x7f

char *to;
char const *from;
---------
strcpy(to,from);
strmsk(to,MASK_PATTERN);
---------

void strmsk(char* str,char mask){
while(*str++){
*str = *str & mask;
}
return;
}

>>698
単にビット数数えてるだけにしか見えんが？

>>698
君はアセンブラは全く読めないようだな。

>>703
お前にはアセンブラに見えるのか？

ただし、
・unsigned で無ければ問題
・最後の行は　a = ( (a>>8) + a ) & 0x3F ; でもいいと

こんな問題知っているかどうかの問題だね。
質問が多いほど分かりづらいからFAQになってるし。

大体ビット数を数えるなんて実務で使用することは無いわけで、
問題のための問題なんだけどね。

はいはい、あなたが実務で使用しなくて良いのは判りましたよ。

でもね。このテクニックは333 形式で 単純和を求めるとか　普通に使っていますよ。

パリティを求めなさいといわれて、あなたの書くコードが目に浮かぶようです。

その333単純和を求めることというのが、そもそも使わないわけで、
パリティを求めるためにわざわざコードを書く人はいません。

いませんって・・・　じゃあ、必要になったらどうするの？

あなたが必要になることはないのは判りました。

でも、今C言語を使う人の半数は　パリティを計算することが必要になる場面があると思いますよ。

> じゃあ、必要になったらどうするの？
明日の朝太陽が昇ってこなかったらどうするの？

気にしすぎｗ

>>709
お前のその狭い頭の範囲が全てだとは考えるな坊主。

パリティ以外じゃ使わないけどな。

問題は、コードレビューなどのときに>>698が出てきたらどうするのか？ということで、
必要な状況で適切に書けるかどうかじゃないでしょ。>>540も同様。

やっぱり分かりにくいから書き直せって言うの？

>>714
複数の処理を一行に集約しても、吐き出されるマシン語
及び実行速度はほとんど同じ。
（540の例なら分けたほうが逆に早いかもしれん）

ってことで、わかりづらいと思う人がいたらわけるべき。
以上

実行速度を追求しない人はC言語で書くな。
例えば2ｎ乗の余剰の計算で%使うやつは他の言語で書け。

むぅ、コーディングなんて設計後の転記作業だぁ・・・・
って、おもっちた時点で、スレ違いどころか板違いか_|￣|○

最適化かぁ、今のコンパイラって賢いしなぁ・・・
楽しかったんだけどなぁ・・・

関数ポインタの配列かぁ・・・マトリクス制御する時、一番綺麗じゃねぇの？

どーしよ、趣味の欄に「プログラミング」って書いてた頃は楽しかったのになぁ・・・
鬱だ・・・

で、ポインタってそんなに難しいの？だけど・・・
面と向かって説明して、理解できなかった奴は居なかったけど
だれもが判るように書くのって、難しそうだにぃ

でも、一生懸命説明しようと努力する事は、必ず＋になって返ってくると
思いますんで、めげずにｶﾞﾝｶﾞｯﾃｸﾗﾊｲ

うじゃうじゃ

>>715
オレは、「わざわざ間延びさせて書く」(たとえば>>657)みたいな書き方のほうが、
逆に「分かりづらい」と思うわけだが、そう申告したら直してくれるの？

>>694-695
>だからシンプルがいいって事になってた時代と文化があったんだと。
>今はそれよりも、わかりやすい方がいいっていう文化が主流になりつつある、と。

>>540は分かりにくいってほどでもないだろ。
それに「分かりやすいほうがいい」ってのは昔からそうなんだよ。全然新しくない。

>> 知ってる奴に教わったことも無いし、そういう本も読まない、そういう奴。
↑こういう奴が分かりにくいって言ったら「分かりにくい」って事になるのか？
ちがうだろ。

1つだけ確かなことは、540の職場のレベルが低いってことだ。

必要になるならないの議論が続いてるようだが、必要になってから
学習（って言っても２、３時間で充分だがな）したほうがいいよ。

>>721
学習(教育?)させるかどうかは経営者が方針として決めることで、
現場に出来ることは、そういう人にも分かるコードを書くことだけだ、
という論理らしいよ

>>722
ああ、組織の規模のことを考慮してなかったよ。大所帯は大変だね。

というか、自己啓発は従業員の義務(とまでは言わないまでもすべきこと)じゃないのか？
それとも、>>540が読めるようになることまで「教育」しなくちゃなんないのか？

>>713
まさか >>698のコードをパリティに使ってる？

>>725
ということは>>698は>>707が言った通り
使い道が無い問題のための問題ってことか。

パリティは 　シフトをlog2(bit数)回　するのは同じだけど、加算ではなく XOR を使う
>>698は
　　16bitをループしながら判定するより1桁早い。

・ポート入力した信号が何個 ON になっているか？
　　たとえばボタンを押した人の数を数えるような場合に使えるよ。

・モノクロビットマップで、ONピクセルの数を数える。
　算術圧縮をする前に、0/1の比率を求めるのに使えるよ。

たいして使用する機会も無さそうだな。

>>728
え？　
圧縮する前に、差分を何度したら一番効率よく圧縮できるかとか判断するのにビット数数えるとか
そういう事はしたことないの？

じゃ、そういう事しないプログラマって何作ってるの？

>>707と>>728にはコアな部分の設計はまかせられんな

普通のコーダーはそういうところを担当させられないからダイジョウブです。
ここはそういう世界の話。

>>729
モノクロビットマップの圧縮を自前で書かないプログラマを思いつきませんか？

自前で書かないということは、誰かが書いてるということだろ

>>731
それで金もらえるのか？いい会社だな〜

ありゃりゃ>>732
>>729 はモノクロビットマップの話じゃないと思うぞ

zlib使えよ。馬鹿ども。

あなたは偉大な人だ。　確かに素晴らしい解決方法だね。

>>719

> >>540は分かりにくいってほどでもないだろ。
熟練したCプログラマには、ね。
わかりにくい要因は山ほど詰まってる。

while っていう単語の意味を考えると受け取ってる型がcharだという時点で不自然、
さらにCで生文字列が0x00で終端するのが通例だという事、
0が偽でそれ以外が真として扱われるという事も直感的に理解できるレベルになってないといけない。
デリファレンスと後置インクリメントとビットandと代入の優先順位も混乱の元だし
そもそもwhileの条件として処理をしてしまっている事や、本文がないのもわかりづらい
(前にブロックがあったりするとdo-whileの終端のwhileに見まちがえる事もある)

> それに「分かりやすいほうがいい」ってのは昔からそうなんだよ。全然新しくない。
多分、わかりやすさ の意味が違うんだと思う。
俺の言ってるわかりやすさってのは人間にとって自然である方向のわかりやすさ。
あなたのいうわかりやすさっていうのは、余分なものがないわかりやすさなんだと思う。

> >> 知ってる奴に教わったことも無いし、そういう本も読まない、そういう奴。
> ↑こういう奴が分かりにくいって言ったら「分かりにくい」って事になるのか？
> ちがうだろ。
だから読んでる本自体が違うし、時代が違う、状況も違う。
今は昔よりも複雑な問題を扱わなければいけないし、
その為の方法論とかも色々覚えなきゃいけない。
注力すべき部分が違うから、必然的に文化も変わってくる。
あなたはアセに固執する人にCの良さを力説した経験とかはない？
それと同じような気持ちを私が今感じてるという事を理解してほしい。

＞だから読んでる本自体が違うし、時代が違う、状況も違う。
とりあえず、読んでいる本を上げてみて。
>>540みたいなコードは書くなって書いてあるんだよね？
具体的に引用してみて。

>>739
> >>540みたいなコードは書くなって書いてあるんだよね？
どこから来た話だろう、これはｗ
頭悪いねｗ

>>738
残念だけど、あなたの書く文章はちっとも判りやすくない。

C言語はそもそも記号的な言語であり、パターンがあり、そのパターンを駆使して書くものだ。

それがわかり難いというならC言語をC言語として使ってないという事だ。
もし選択肢があるなら そういうコードが書けない言語を選ぶべきだね。

>>740
というか、何にも読んでないんだろ？正直に言えって。

>> >>540は分かりにくいってほどでもないだろ。
>熟練したCプログラマには、ね。
オレって熟練してたんだ…知らなｶﾀｰﾖ

あと、Ｃ言語がよく分かってない奴にプログラム書いてほしくないな…危なっかしくて…

>>742
ああ、これが「ということにしたい」ってやつかｗ

自分は Windows環境なら Delphiが一番好きな言語だ。

でも、C言語では >>540のように書くぞ。　どうしてかというと、それがC言語の書き方だからだ。

少なくとも>>728の様な人は
ライブラリが全てやってくれるような言語しか経験がないのだろう。
そのライブラリを記述する言語であるCはやって欲しくないわな。

>>744
読んでいる本を示せないんだから、そう思われても仕方ないでしょう？

>>747
話がそれてますよ〜。

>>738
> さらにCで生文字列が0x00で終端するのが通例だという事、
> 0が偽でそれ以外が真として扱われるという事も直感的に理解できるレベルになってないといけない。
曲り形にもCプログラマなら当然だ。

K&RでなくてもCの入門書なら
while ( *to++ = *from++ );
なんてコードは、ポインタを使った文字列操作の説明で出てくるわけで、
それに毛が生えた程度を「わかりにくい」だとか言ってるヤツは
入門書さえまともに勉強してないって事だろ。

>>742
10日でわかるVB入門ぐらいは読んでるかもな。

Cの本しか読んでない奴は金がかからなくていいよな。
その代わり最近の流れがわからなくなるみたいだけど。

なんでもかんでもﾗｲﾌﾞﾗﾘまかせの職業Cプログラマなんてｲﾗﾈ

>>751
だから、読んでる本晒してみろって。

>>753
DOS/Vﾏｶﾞｼﾞﾝ

>>753
埴谷雄高「死霊」

>>753
まだ晒されてないけど、先にやっといてあげる。

>>751
けっ！そんなDQN本読んでるからお前頭腐ってるんだよっ！

>>753
プログラミング言語C
プログラミング作法
達人プログラマー
オブジェクト指向による再利用のためのデザインパターン
アナリシスパターン
Effective C++
More Effective C++
Exceptional C++
More Exceptional C++
Modern C++ design

他にも色々ありすぎて書ききれないです。
上に挙げたのは比較的ドメイン依存の少なそうな本で、今ちゃんと本棚に並んでる本。
他にもいろいろある。

今の話題に合いそうなのは、
＞プログラミング作法
＞達人プログラマー
このへんかな？

正直、>>698のコード、誰か解説してくだちい。
上位ビットにビット数をカウントしながら、下位ビットにまだ処理してない分を残してる？
？？？？？？？？？？？？？？？？？？？？？

どうしてこれでビット数が数えられるのかよくわかりません。

>>759
絵を書いてみたら？
ビットが収まる箱を描いてそれをシフトして足してる絵を書けば判ると思うよ。

最初の1回目は
abcdefghIJKLMNOP
　　↓
0a0c0e0g0I0K0M0O
0b0d0f0h0J0L0N0P

1+1 は２で上のビットは双方0だからそこにちゃんと収まるという仕掛け


2段目は 2bit+2bit で max 4で 4bit分の隙間があるから十分に収まる

>>759
こいつは、最初2ビットで考えるとわかりやすい。
2進数で11(=3)のビット数を数えるとすると、
>>698の1行目と同じものを2進数であらわせば、

((11 & 10) >> 1) + (11 & 01)
=(10>>1) + 01
=01 + 01
=10(=2個)

つまり最初の1行で、2ビットずつその区間にあったビット数が数えられることになる。
最終的に2進数1桁同士の足し算になるので桁あふれが起こらないことに注目しておく。

次は同じ事を2ビットずつ組で(4ビットで)行う。
たとえば、1101の場合、>>698の1行目での計算結果は、1001だ。
2〜3ビット目に1が2個、0〜1ビット目に1が1個、と読める。

((1001 & 1100) >> 2) + (1001 & 0011)
=(1000 >> 2) + 0001
=0010 + 0001
=0011(=3個)

これを8ビット、16ビット32ビットと拡張していけば、最終的に1の数が求まる。

ﾎﾟｲｿﾀってWindowsのショートカットと一緒だろ？

>>759
（１）8個所で隣合うbitt同士を加算
（２）４箇所で隣合う（１）の結果同士を加算
（３）２箇所で隣合う（２）の結果同士を加算
（４）１箇所で隣合う（３）の結果を加算

>>762
いや、BTRONの実身、借身です。

>>760 >>761 >>763
ありが�d
特に >>761 さんの説明がわかりやすくてよかったです。
うーむ、こういうのも奥が深いなぁ。

普段はわかりにくくて効率的なコードより非効率でもわかりやすいコードを書くタイプなのですが、
効率的な方を知らなくてやるのと、そうでないのとでは大違いですからね。
皆様のおかげでまた引き出しが増えました。ありがとうございました。

じゃあ次は この手法を　パリティを計算するのに応用してみよう。

16bitのパリティを求めてみては？

>>758
たとえば、プログラミング書法にはこんな記述がある(p.30)。
>慣用句によって一貫性を確保しよう
>自然言語と同じようにプログラミング言語にも慣用句(イディオム)がある。 これは、よくある
>コードを書くときに経験豊富なプログラマが使用する慣習的な書き方のことだ。どんな言語
>でも、その言語の慣用句になじむことが学習の中心となる。

ただ、その前に
>複雑な式は分割しよう
とか
>明快に書こう
とかいう項目があるけどね。

俺的には、>>540は慣用句的、>>635はやりすぎ。

>>765
＞普段はわかりにくくて効率的なコードより非効率でもわかりやすいコードを書くタイプなのですが、
これは>>540の問題とは違って、どっちかというとアルゴリズムのほうだからなぁ。
クイックソートが分かりづらいからバブルソートで実装する、とかそういう話に似てる。

while ( *to++ = *from++ );
をオレが書かない理由の一つに
gcc -Wall
とコンパイルすると怒られるからっていうのがある。
バグが見つかることもあるんで、warningは厳し目に設定する
ようにしてる。

ということは、
while ( (*to++ = *from++) != '\0');
はOKということ？

あ、ボーランドのコンパイラだっけ？↑でも、
while()の後に有効な分が無いってwarning出る奴もある。

まあ確かに　その２つは典型的な C ならではのバグの温床だね。
でも 典型的な C スタイルのコードでもあるし、

否定も肯定も難しいね。 C の利点でもあり欠点なのが ポインタって事かもね。

>>770
他にも++を使うときは
i++；
というように必ず単独の文にするという偏った好みもあるんだけど、
それよりもまっとうな理由かなと思って書いてみた。

典型例１、　= と == の打ち間違い
典型例２、　セミコロンの入力ミス

って事か・・・

>>773
げ、典型例２の方は知らない。

while (…);
{
…
}
こう入力ミスするってこと？

>>698 のもっとも優れている点は、分岐が全くないこと。
処理速度をCPUレベルまで考えると、この効果は大きい。
もちろん、業種によっては、まったく恩恵を受けない場合も多いだろう。

>>774 やった事ないの？　普段1回ループするだけなんでなかなか気付かなかった事とかは？

>>776
オレはあるぜ。アホか＞オレ

その１
/* コピー */
while ( *to++ = *from )

/* ほげほげ処理 */
hoge_func(foo, bar);

その２
int count = 0;
while (*from)
　　*to++ = *from++;
　　count++; /* 11/1修正 */

その２はちょっと違うか。。。
(修正個所に「修正」ってコメント入れる是非はともかくね。)

× while ( *to++ = *from )
○ while ( *to++ = *from++ )

じつはこれも時々やる。

>>776
あってるの？

while (…);
while (…) …;
while (…) {
…
}
というパターンしか書かないんで
while (…); …;
while (…); {
こうなると気づきやすいとか。
昔、やったような記憶もあるんだが、もしかしたら
他人の書いたソースを弄ったときかも。

典型例１は、代入を比較するという逆にやつなら
最近やった。

思い出した。
あれはえらくてんぱってたときだ。

確かバイトくんのソースを手直ししようとして
for (…);
というのコピペして
for (…);
{
…
}
と書いたんだった。気づかずに…
デバッグして、forの行がおかしいとまで追い込んだんだけど、
何故かわからない。てんぱってる状態の自分じゃ無理とあきらめ
先輩捕まえて
「すみません。この行にバグがあるはずなんだけどみてもらえませんか」
と頼んだっけ。
先輩は一分とかからずに指摘してくれました。

>>780 誰でも(？）やる「てんぱってる状態」の時の、後で思い返すと恥ずかしい体験
は、とても微笑ましい。長時間労働しなきゃテンパラないんだけどね。

他人のプログラムのミスはすぐ見つけられるけど、自分のはなかなか見つからないんだよね。
自分で正しいと思って作ったんだから正しいはずだ、って想いが奥底にあるたなのかどうかは
知らないけど。

>>776
ifやwhileは処理が無くても、一行でも必ずブレイス付けるからやった事ないでつ。
俺のコードに出てくるwhile(cond);は必ずdo-whileのwhileなのでつ。

そしてブロックの後は一行開けるのでつ。
Cの人は処理上の意味が途切れても行を開けない人が多くて嫌でつ。

>>783
>Cの人は処理上の意味が途切れても行を開けない人が多くて嫌でつ。
うん。関数内には全然／絶対、空行を作らないよ。平均行数24くらいだし。

>>784
一画面で見れると見やすいとか思ってる派ですね。

ifのブロックの後に(else や else if以外の)関係ないifブロックを
空行なしではじめちゃったりする人ですね。

ついでにいうと演算子の左右にスペース入れない人ですか？特にビット演算子の左右。

詰まってりゃいいっていう時代はとっくに終わりましたよ。

＞詰まってりゃいいっていう時代はとっくに終わりましたよ。
そんな時代あったの？MSX BASICくらいしか知らない
IFA=0THENGOTO10

>>785
そういうのはツールが直してくれるもんだろ。

>>785
>ついでにいうと演算子の左右にスペース入れない人ですか？特にビット演算子の左右。
>詰まってりゃいいっていう時代はとっくに終わりましたよ。

激しく意味不明なんだが。
おまえは空白入れてりゃいいと思ってんのか？
しかもそれが時代の最先端とでも思ってるのか？

ソレ５年くらい前に流行ったよね。　ニフテイでコード晒したら　そんなイヤミ言われた。
で、たぶん、未だに印刷してソースを見てる人なのかも。

それはそれで格好いいよね。

>>786
C厨には多いよ。

>>787
ツールで直す事すらしないんだよ。

>>788
最先端？意味不明なのはあなたですね。
区切りをちゃんと付けないのが時代遅れなだけですよ。

>>789
印刷するかどうかと関係あるのでしょうか？
区切りをつけないと画面上でも見辛いと思うのですが。

最近は、エディタで色つけて表示してるから、前ほど空白は開けなくなったけど、
それでもまとまった処理単位では開けるな。

というか、その前にまとまった処理単位の前にはコメントつけないか？

＞C厨には多いよ。
オレもBASICから移行したばかりのころは、詰め詰めだったな。
意味もなく1行にいっぱい書いてみたり(マルチステートメント！)。

つか、まとまった処理になってるなら関数化しろよ・・・・

>>792
おまえはアホか？
オマエの作る関数内の処理はすべてばらばらなのか？

>>793
意味わかってるくせにごちゃごちゃいってんじゃねーよ

>>794
なら、さいしょからごちゃごちゃ言うな。

>>795
何が「なら」なのか意味不明。
自分のやらかしたアホな振る舞いを無理矢理人のせいにしないように。

>>796
ん？>>792=>>794じゃ無かったのか？
だったら失礼。

>>785
俺のスタイルを勝手に決めるな。全然違うぞ。
垂直方向（行方向）は詰まっているが、水平方向（欄方向）はかなりスペースがある。
マルチステートメントは無い。
ｃの設計者はプログラマだから「短く書きたい」っていう要求が言語仕様に反映されているんだ。
「短く」ってのは「行方向」と「欄方向」の双方だが、「行方向」にのみ適用だ。
>>792 同意。
200行くらいの関数を書いおいて、「短いでしょ」という同意を求める発言を聞くと、
認識の違いに頭かクラクラする。
関数の適切な粒度については表明しないけど、一言だけ。
「全く無関係な二種の変数が１関数内に存在する場合、その関数は長すぎる」

なんか妄想が激しいようだが、だいたい同意。

　　 ／￣￣'' -、
　 （　　　 ／ )　ヽ 　ジャーパネットー ジャパネットー♪ 夢のジャパネットたかたー♪
　　i　r-,,,, ／,,,,　）
　（ >|　●　 ●//
　 `‐|　　 Ｕ　 /ノ　 　やった！！高田社長様が>>800ｇｅｔだ！！
　　　＼　━ /
　　 ((Οっ V> 　　　　　　オラてめえら！！ウチの商品を買えウンコども！
　　　 ＼　　'oヽ
　　　　　|,,,,,,∧|
　　　　 /　 ∧ ＼　　　　　>>801　 今さらCPUが1GHz以下の低速パソコンなんか使ってんじゃねーよ(プ
　　　／　／　ヽ　ヽ　　　　>>802　 15インチのＣＲＴなんか使ってると目を悪くするぜ(プ
　　　ト-<　　　 |_／'.'.┐　 >>803　 超低画質プリンタで来年の年賀状作成か。おめでてーな(プ
.　　　　　　　　　　　　　　　>>804　 50万画素以下のカメラでプロ気取りか、おめでてーな(プ
.　　　　　　　　　　　　　　　>>805　 親戚の前で恥をかく前に電子辞書を使って日本語覚えろよ(プ
.　　　　　　　　　　　　　　　>>806　 今やMP3の時代なのに、カセットテープなんて使うなよ(プ
.　　　　　　　　　　　　　　　>>807　 VHSより時代はDVD・HDDレコーダーだよ、３倍ヲタク君（プ
.　　　　　　　　　　　　　　　>>808　 今さら８ミリビデオカメラなんて使うなよ。今やDVかDVDの時代だぜ(プ
.　　　　　　　　　　　　　　　>>809以降は金利手数料は自分で負担しとけ(プ

>>798
行数で数えて何行で小さいとか考えてるから適切な空行を入れられなくなっちゃってるんじゃないですか？
関数の粒度に関しては概ね同意できるし、横方向への適切な空白は入れてるんでしょう？
行数に拘らずに空行を入れても適切な粒度の関数は適切なままで、より読みやすくなると思うんですけど。

>798じゃないが、まともな粒度で関数作ってりゃ関数内の空行なんて
入れても入れなくても大差ないとおもうけどな。
まあ、「一行でも必ずブレイスを付けて、ブロックの後には必ず空行を入れる」
とか言ってるのがいたが、その流儀に従って、

if( flagA )
{
　　一行
}

if( flagB )
{
　　一行
}

if( flagC )
{
　　一行
}

とかやるなら別だが…漏れには冗長なだけに見えるな。

「必ず」とかいうルールにはろくなものが無いな。

>>802
短く書くなら、こんなんどうだ？

flagA && 一行;
flagB && 一行;
flagC && 一行;

まあ、場合によっては、読みやすいこともあるが・・・・

なんにしろ、重要なのは「他人にどう見せるか」だろ。
空白や空行を法則にしたがって無条件に入れるだけが能じゃない。
メリハリのある、読みやすいソースを書くことがPGの技量ってもんだ。

# ・・・・まあ、漏れはどちらかといえば「短いのが好き派」だが。

>>804
その書き方だと
「"一行"は式しか書けない」
とかいうツッコミが来ると思うよ。

「短く簡潔に」という方針自体は真だと思うけど、忠実に守ろうとしたのか、
関数がぶつ切りになっててあちこち飛びまくる(しかも呼び先を見に行かないと
何やってるのかわからん)読んでてむかつくクソコードを書く奴が多くて、
そのルールには、あんまりいい印象を持ってない。俺は、だけど。

なにを今更・・・
ソースにメリハリなんていらないだろ。
統一されたスタイル
必要なのはそれだけだ。
見てわかるソース
読まなきゃわからんソースなんていらん。

図を駆使するのか？＞見て分かる

>>765
>うーむ、こういうのも奥が深いなぁ。

だまされるな。
実際はこんな糞コードよりも「表引き」の方がずっと早い。

>>809
バレルシフタ持ってない組込用途ならおっしゃる通り
16bitなら8ビットに別けて8bitでテーブル引いて加算する方がパフォーマンスが良いね。

でも、パソコンで画像処理とかだと、
・テーブル引きは、たいてい画像データが大きいからキャッシュロスの率は大きくなるし　
・シフト ADD はCPUで並列処理されるし
・MMXでさらに大きい幅一度に計算出来るし

>>810
>でも、パソコンで画像処理とかだと、
実際にコード吐かせて実行してみれ。
比較の対象にもならんぞ。

>>785
>>802
if (cond) { one-liner; }
if (cond) { one-liner; }
if (cond) { one-liner; }

if 　　　(cond) { one-liner; }
else if (cond) { one-liner; }
else　　　(cond) { one-liner; }

この場合はブロックの直後でも空行は要らない。elseが続くかどうか見ればすぐわかるから。

俺、最近　行をあわせるのが好きで

/**/ if (cond1)・・
else if (cond2)・・
else /*----*/・・

てな感じで書いてる。　

SURRENDER yourself to me!

>>807
見てわかるってのはいったいなんなんだ(w
読みやすいソース書けよ。
規則どおりに書くのが能じゃない。

たとえば、下の三行見比べてみろ

a = c + b * 8 ;

a = c+b * 8 ;

a=c+b*8 ;

>>815
カラードエディタで見れば一番下が一番見易いな。
印刷したら　一番上が見易そうだ。

でもまあ、コードレビューする時に嫌な奴がいると、そういうの突っ込まれるんだろうな。
苦労してるんだろなあ。

>>804
演算子の処理順序に依存するコードは
よろしくないと
カニハンさんが申しておりました。

>>815
画面上でも印刷しても一番上が見やすい。
一番下はイマイチ。
最悪なのは中段。

つか、演算子の優先度間違ってねーか？

>>813
行じゃなくて列でしょ？
それとそこにコメントを使うのはいかがなものか？

>>814
We Aa inferiAa to each oZer〜♪
We surrendAa every night♪

カッコ使えよ。

正解は、
a = c + b*8;

>>815==>>822
カッコ使えよ。

その程度でつかうか？普通。とﾏｼﾞﾚｽ

>>819
つーわけで、空白をうまく使えば、
本来やりたかった意図が第三者に伝わりやすいわけだ。

空白も、立派にコーディング技術の一つだ。


>>823
ん？>>822は俺じゃねーよ。

>>825
だからといって、何でも空ければいいというわけではない、とか言っといてよ。
そうじゃないと、スペース入れられるところ全てにいれちゃうバカが出てくるからさ！

>>815==>>822==>>826

>>827
意味不明なんだが・・・・

>>827
括弧派必死だな

まったくスレ読んでないけど、
「エキスパートCプログラミング」読んで全てのもやもやがふっとんだぞ。

加減乗除には括弧は不用。（小学校出てれば知っているはず）
その他の全ての演算には括弧を使う。
という「スタイル」を使っている。
14だか17だかある演算子の優先順位を記憶出来やしないし、する気もない。
仮に出来たとしても、「スタイル」は変えない。

>>831
お前は、こんな書き方するのか？
馬鹿で塚？
( x = ( ( ( !(a==0) ) || ( !(b==0) ) ? ( a + b ) : ( a-b ) ) )

>>832 少なくともお前は「揚げ足取り野郎」だな。しかも括弧の対応がおかしいぞ。

なんとかスレを盛り上げようとしてるんじゃないか。　努力はかってやれ

×その他の全ての演算には括弧を使う。
○演算子の優先順位が曖昧な場合には括弧を使う。

*p++

こんなのは直感的じゃない典型例だな。

>>836
括弧を使っても何もかわらんと思うが・・・・

*(p++)
(*p)++

>>838
後者は違うだろ・・・・

つか、*p++ を読めない香具師は *(p++) もまともによめねーだろ

>>835
とまあ、まったく意味が違うわけだが・・・・

>>839
後者は違うって何が？参照剥がし後のオブジェクトをインクリメントするという意味になるだけだが。

＞*p++ を読めない香具師は *(p++) もまともによめねーだろ
はじめから読めない香具師の話はしてない。
わかりやすい(直感的)か、わかりにくい(非直感的)かの話をしてる。

>>841
藻前は、*p++ が 「参照剥がし後のオブジェクトをインクリメントする」
などと直感的に勘違いするのか？

お前の直感なんて、あてになんねーよ。
「読めない香具師」ってのは藻前のことだ。

こうやって自分以外の人間の感覚を否定する態度で生きてりゃ、
自分のやり方に無駄に自信持っちゃうのも無理ないな・・・。

藻前ら優秀だな
洩れは>>836が>>838のどっちの意味なのかワカラネーもん

>>844　そういうときは、必ず、すぐに、演算子の優先順位一覧表を見るんだ。

というか、プログラム始める時は、「コピペライブラリ.txt」 ってファイル作って
ショートカットを作っておいて

/* pからqへの文字列の複製 */
while( *q++ = *p++);

とかさ、一杯書き溜めておけよ。

>>820
> We Aa inferiAa to each oZer〜♪
> We surrendAa every night♪

translated.
\begin{quotation}
　We are inferior to each other.
　We surrender every night.
\end{quotation}

\HUGE{SURRENDER yourself to my pointer! }

>>844
さすがにそれは経験不足だろ（勉強不足とはちと違う）

馬鹿だなお前ら。コードの内容がわからなかったら、書いた奴に
聞きに行けば良いんだよ。書いた奴が死んでる？イタコを呼べ！
もう退職して別の会社にいる？電話をかけろ！読んですぐわかる
コードを書かない奴はそうやって追い詰めろ！

>>849
？　労働著作だから退職したらどうしようもないよ。
労働著作だから会社が管理する事なんだからさ

>>849
待っててね。どこまでも追いかけていくから。

>>850
そ　ん　な　こ　と、　関　係　ね　ー　ん　だ　よ。地　獄　の
果　て　ま　で　追　い　詰　め　て　説　明　さ　せ　る　ぞ　！

粘着

このスレも馬鹿がふえてきたな

>>849
おしえてほしかったら100万円だせ

Cカップでボインがどうしました？

ここは素人が集まるスレなんだ

>>854
お前のそれみたいな無内容なレスが増えたよな

>>849
君の執念深さは充分わかったよ。書いた奴にコンタクト出来て、聞けばイイだろ。
でも書いた奴が説明できればいいんだけどね。「説明できない場合もある」とは思わんのか。

C厨はポインタ演算でスパゲティコード量産したくらいで
自分が玄人になったと勘違いしている厨房が多いからタチが悪くて嫌い

クンニリングスの方が難しいでつ

>>860
「C厨は厨房が多い」ってのもなんか変な文章だね。

プログラマーの英語力はどれくらいですか？
ポインタってそんなに難しいの？
オブジェクト指向を理解できんとが何で悪いとや？

おまいらよ、おまいらにとって、英語、ポインタ、オブジェクト指向は、鬼門らしいな。
まあ英語はＰＧだけでなく、日本人全体にとっての鬼門だけどな…。
日本人は、英語を覚えられないだけでなく、ひとつの分野で一人前になるための鬼門を超えることができないということだな。

>>860
主語が4つもある。

そして真の主語はない。

ついさっき悟りが開けた気がしたので
始めて１ヶ月の素人から言わせてもらうと

ポインタや参照は
宣言、代入時、引数で使うときに混乱を招くんじゃないかと思います
int a=1;　が宣言されているものとして

一、単独宣言の場合
ポインタ　：　int *p;
参照　　　：　×（無し）
普通の変数：int b;

二、後で代入の場合
ポインタ　： p=&a
参照　　　： ×（無し）
普通の変数：b=a; or b=0;

三、宣言時代入の場合
ポインタ　：　int *p=&a;
参照　　　：　int &r=a;
普通の変数：　int b=a;

四、引数に渡す場合
ポインタ　：f（int *p）渡すとき→f(&a)使うとき *a
参照　　　：f（int &r）渡すとき→f(a)使うとき a
普通の変数：f（int b） 渡すとき→f(a) or f(0)使うとき a

この、一,二　と　三,四のポインタのせいなどで混乱してました。
まだポインタの1割も理解してないかもしれませんが勘弁ください。
いまだ関数の型にポインタ、参照にする意味が分かってません。
間違ってたら訂正お願いします。

ﾎﾟｲﾝﾀという名前が良くない。
ｲﾝﾎﾟﾀにすると非常にわかりやすい。
プログラム言語がわかりにくいのは、最初に日本語にした奴が無能だから。

おれは、>>866が何を言いたいのかが分からない…

>>867
もし最初に日本語にした奴が不能だったらｲﾝﾎﾟﾀになっていたということか。
しかし、歴史にIFは無い…

>>868
えーと、分かりにくかったですか・・・要するに

宣言と同時に初期化するときは　*p=&a　なのに
宣言した後に代入するときは　p=&a　っていうのはどういうことか？

普通に代入するときは　p=&a　なのに
引数に渡すときは　*p=&a（の関係に見える）になるのはどういうことか？

と思ってたんです。

>>869
ﾎﾟｲﾝﾀよりおまいの文章のほうがわかりにくいよ。

>>869
ポインタを宣言する時はアスタリスクが必要なの。

>>870-871
分かりませんか・・・すいませんでした、上のは見なかったことにしてください

>>869
キツイようだが正直全然わかってないと思うよ
その前にアドレスっの事が分かっていないような気がするんだよね、
もう少しいい本を読んだ方がいいぞ
俺も独学でCを勉強してたがマジで本によって滅茶苦茶書いてあるぞ
アマゾン辺りで評価高い本を調べたほうがいいぞ
(ここで本の題名は書いたら宣伝と思われるので)

>>873
助言どうもです、精進します。

本丸写しでプログラム書いたつもりになってるから>>869のようになる。

>>869
873なのだがサンプルのコードを上げてみたらいいんじゃないのかな？
だれかが理解できてるかどうかは判断してくれると思うぞ
俺は頭が良くないのでホントにエクセルでマスを作って何度も何度も
メモリの動きを書いてポインタについて理解を深めた
処理によってどれだけのメモリが使われるとかも大事だし、ホントに
凄く処理の早さが違うぞ
まーポインタますたーの道は遠いぞ！

>>875-876
いえ、まだプログラムを書くというレベルですらないのです
皆さんのおかげで分かったことはポインタがそんな生易しいものではないということです・・・

>>866
着眼点は良いが、ひとつだけ注意しておく。

>三、宣言時代入の場合
>ポインタ　：　int *p=&a;
>参照　　　：　int &r=a;
>普通の変数：　int b=a;

これは代入ではない。"初期化" だ。
代入（演算子）と同じ '=' 記号を使用している為に混乱しやすい。

また変な奴が登場しました(w

>>866
>宣言と同時に初期化するときは　*p=&a　なのに
>宣言した後に代入するときは　p=&a　っていうのはどういうことか？

int *p=&a;

は「（初期化）構文」だが

p=&a;

は「（代入）式」だ。

見た目はちょっと似ているが、"文法的" にはまったくの別物。

「初期化」という言葉が誤解を生みそうなので、もう一つ例を挙げる。

int *p;

p = &a;

ここで行っている変数 p への"初期化" 操作の部分は
Ｃ言語の構文論上では「初期化」ではなく「代入」と呼ぶ。

>>880
君は大学どこを出たの？
偏差値はいくつだった？ポインタが理解できる偏差値だったかい？

沢村氏ね

T E S T

int *p; じゃなくて int * p; となぜ理解できないのだろう？

>>866
要は「まぎらわしいから何とかしる！」ってことか。
ならばint* p;みたく*を型の方につけて書けばいいと思うが。
（それだとint *p,*q;みたいな連続宣言ができないか）

>>879
変なやつですいません
>>878
うーん、難しいですねなんとか理解してみます
>>885
そこがなぜかいまいち分からないのです
>>886
始めはそんな感じだったのですが、微妙に分かった気がしたのです
今後はその書き方にしてみます。

>>886
その書き方も、昔からの論争点なんだよ。否定派が優勢だったと記憶しているが。
>>887
＞今後はその書き方にしてみます。
個人的にはお勧めできない。自らのリスクでやってね。

>>888
細かいところもあって奥が深いですね・・・
やりやすいほうにしてみます

>>866
仮にＣ言語の構文規則（例：http://www.lysator.liu.se/c/ANSI-C-grammar-y.html ）
の一部、 init_declarator の定義が
init_declarator
    : declarator
    | declarator '@' initializer
    ;
だったとすると、Ｃ言語は以下のような言語になっていただろう。
int main()
{
    char *p, *q @ "hello world\n";
    p = q;
    printf( p );
    return 0;
}
これでも処理系としては何の問題もなく構文解析できる。
ただ現在のＣ言語の定義では同じ '=' 記号を使用しているだけ。

神聖ポインタ帝國

始めて１ヶ月の素人に構文規則がどうこう言っている奴がいるな。

>>877
>皆さんのおかげで分かったことはポインタがそんな生易しいものではないということです・・・
１ヶ月でそこまで理解できれば、正直大したものだと思う。
あとはあまり深く考えずに、何度もコードを書いてコンパイルして
体で覚えるようにすればいい。
細かい約束事を調べるのは、後回しでいい。

>>892
問題点が構文規則（の不出来）に由来するものだったからな。

>>866
int *p; /* C使いに多い */
int* p; // C++使いに多い
int * p; # 掛け算ですか？

ま、最後はネタとして…
前者はK&Rからの伝統ある書法で一行に複数ポインタを宣言しても違和感がなかったり
ポインタとポインティーをセットで宣言するときもわかりやすい。

後者はポインタを表す記号まで型名と考えるタイプであなたがしている各種勘違いが起こりにくい。
問題は関数ポインタの表記ルールには適応できない事(ただし関数ポインタはtypedefするのが普通なので通常問題ない)

個人的には後者がお勧め。
後者を突き詰めていくとC/C++の引数渡しの方法には値渡ししかないという境地まで行き着く。
「ポインタ渡しは？C++には参照渡しもあるよ」という意見は
後者で悟った人間にとっては「その考えは直交性が低いな…フッ…。」という事になる。

後者にC++使いが多いというのは、ある意味ではそういう物事の直交性とかを考えるのが苦手なタイプは
C++を使いこなせなかったのではないかとさえ邪推する。

と、猛烈に後者を推しながらですが、別に前者が悪いというわけではないですよ。
数的には前者派のが優勢ですので、今後あちこちでうまくわたっていくには前者の方が好ましいかもしれませんし。

でも「C/C++の引数渡しの方法には値渡ししかない」という言葉の意味は
考えてみてもらえると、あなたの今後に有益かもしれません。