C言語なら俺に聞け 142 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
s[4]か、サイズ未指定のs[]にする。 \nを追加する。 strlenの返却値はsize_tだから、%luは間違い。 組み込みのショボいライブラリじゃ使えなかったりするから unsigned intにキャストして%u でいいや キャスト毛嫌いしてたんだけど、size_t や int*_t シリーズを printf 書式で使う時のベストプラクティスだと気付いてしまったよ。 サイズの変わる型キャストは、(通常無視できる程度の)少しだけコストがかかることに言及しておこう。 わずかに時間と計算量がかかるという意味のコストね。 printf使ってるときなら、無視できるレベルだな 大抵の場合、暗黙でintに変換されるので%dで問題ない >>63 64ビットで渡すより32ビットで渡す方が普通は速い >>65 intより大きいサイズはintに変換されない >>65 問題大ありだよ 64bit 環境では、sizeof sizeof 1 == 8 だぞ 脇道に逸れるが整数のサイズってどいつもこいつもイマイチだね char 8 short 16 int 32 long 64 long long 128 と、せっかく5階級あるのを無駄なく使えるようになってない そんなに細かく分ける意味あんのかね。 64bitだけでいいだろ。 Makefileの書き方なんだけど makeが実行されているときに 今何を実行してるか表示されるけど 「なんでこれが実行されているんか」の理由も表示したい 依存関係の hoge: fuga を表示したい .c.o: @echo $@:$^ $(CC) $(CFLAGS) -c $< みたいに書いたりしてんだけど、全部に書くのもダサい気がするし 良い方法はないでしょうか >>72 128が標準にあれば使い途いろいろあるぞ >>73 GNU make なら -d (デバグ表示)とかは? ただ「なぜこれが実行される」って、ファイルの更新日時ぐらいしか ないと思うけど >>75 このコマンドを実行したのは○○より△△が古いから って言うのを知りたいんでしょ $^ の意味も知らないならROMってなよ >>73 make コマンド自体に手を入れた方が早いかも すみません初歩的なことですが・・ 前置インクリメントa++ 後置インクリメント++a がありますが、a=a+1は後置になりますよね? b=a++ と b= a= a+1 は違う気がする。 回答有難うございます 実験してみたのですが、a=a+1は前置(a++)にも後置(++a)にもなるのですね http://i.imgur.com/teLsUGY.jpg a[i++] = i; は悪魔召還だけど インクリメント演算子なしのこれ a[i =i+1] = i; も鼻から悪魔になるのかな >>78 >前置インクリメントa++ >後置インクリメント++a 考え方が逆 変数を基準に考えるのではなく演算子を基準に考える 前置インクリメント++a : 演算子を’前’置した場合、変数(式)の評価’前’に演算子が適用される 後置インクリメントa++ : 演算子を’後’置した場合、変数(式)の評価’後’に演算子が適用される >>84 なるでしょ iの変更と最後のiの評価の間に順序性がない事に変わりはない i = i + 1; の、iの変更と最後のiの評価の間の順序性は? デバッガはデバッガで起動すればいいし、printf があるし。 >>87 6.5.16 Assignment operators 「The side effect of updating the stored value of the left operand is sequenced after the value computations of the left and right operands. The evaluations of the operands are unsequenced.」 左オペランドの変更は、左右オペランドの評価の後 >>84 MISRA-C で、禁止されている a[式] この式に、副作用があったら、ダメ。 バグるから >>91 thx だよな、そこは断り書きが必要な箇所 >>92 バグが入りやすい書き方ってだけでバグるわけじゃない 事実上どうなっているという話ではなく 理屈の上でどうなのかという話 ちゃんと断り書きがあったからめでたしだが そうでなかったら大変だった defineした定数を文字列定数にいれるにはどうしたらいいの? #define EOL 0x0d const char version_message[] = "Version 1.0\x0d" ↑この文字列の改行コードに定数EOLを展開した値を入れたいです。 typedef struct hoge { int a; int b; } hoge; hoge h = {1, 2}; 構造体に含まれるメンバ名と値を全て出力する方法を教えてください 上の構造体なら a,1 b,2 と出力したいです >>100 小さな部品を繋いで大きなものを得るのはとても簡単にできるけど 部分を削って小さな部品を得るのはとても大変なのよ だから本来は改行文字は機能的にレイアウトなのでデータとは分離しておいて 表示なりなんなりするときに結合して使うのが望ましいもちろんVersionと数字もね その上で既存コードのメンテ等でどうしても必要なら>>101 がベスト >>100 #define EOLSTR "\x0d" const char version_message[] = "Version 1.0" EOLSTR; >>104 それは迷ったんだよねー 次点でその文字列をマクロで作ることも考えたけどあかんかったw >>102 変数名はあくまで人間が扱いやすいように何らかの領域(一般的にメモリアドレス)に付けるあだ名であって プログラム(コンピュータ)的にはメモリアドレスのほうが扱いやすいのであだ名は不要(アドレスのほうはプログラム的に出せる) なのであだ名のほうが欲しいなら以下のように直書きするしかない printf("%s,%d\n", "a", h.a); >>106 そうなんですか・・・ 全部直書きするのキツイのであだ名がなくてもかまわないのでこの場合の方法ないでしょうか? >>101 ,104、ありがとうございます、 PCとUSBシリアルで通信する組み込み機器のドライバをメンテしていて 受信したテキストの終端検出にEOLはキャラクタで扱っているし 送信する固定テキストは改行含めてリテラルにしたく プリプロセッサの#か##で連結でなんとかできないか悩んでました。 メモリアドレスを出力させればいいんじゃない? %pで&aを表示できるはず 与えられた変数から、メンバ名とその値を再帰的に列挙して欲しいんだろうけど そんな都合の良い言語じゃないから自分で並べるしかない 必要に応じて毎回並べるか 並べて出力したものを関数化しといてそれを呼び出すか 再帰的に列挙は自動だととんでもない情報量になったりするからな そこから欲しい情報をどうやって抜き出すかが頭の使いどころ >>100 #include <stdio.h> #define EOL x0a #define _STRING(s) # s #define STRING(s) _STRING(s) #define _VALUE(s) 0 ## s #define VALUE(s) _VALUE(s) char a[] = "Hello" STRING(\EOL); void main(void) { int n; n = VALUE(EOL); printf("%02x [%s] \n", n, a); } >>115 これってさ、メンバ名をconst char*にするんだよね? >>115 でいいと思うけど、 そもそもこれがしたい場合にC言語を使うのが間違いでしょ。 動的言語かリクレクションがある言語を使えばいいだけ。 ちなみにVC++/CLIでよければリフレクションが使えるけどね。 質問者には無理だろうけど。 レベルからいって>>108 が当たりだろうね。 >>117 #x の所? そうじゃないかな。gcc -E とかやって見てみるとわかると思うが、 h.a は単純に "h.a" になっている。 >>118 C使わなきゃいいってのはその通りだが、それを言っちゃあお終いよ。 構造体のメンバ名がほしいとかデバッグ以外に何があるの >>120 有名どころはGUIのバインディング。 例えばWPFは自動的にリクレクションを使ってこれをやってくれる。詳細は以下参照。 http://www.atmarkit.co.jp/ait/articles/1010/08/news123.html ただ、Cのアプリでこれは要らんし、今時生CでGUIもないよな? テキストベースで構造体の値のファイルへの保存と読み込みをしたいのかな マクロでどうにかできるかとも考えたが壊れる対処のし様がない #define pr(a,b) printf(pr_##a(b)) #define pr_test_t(b) "#b{i:%d,s:%s}", (b).i, (b).s typedef strct{int i; char *s;}test_t; pr((test_t){.i=999; .s="abc"}); Cはウンコ言語なのでリフレクションはありませんの一言で終わる質問 >>124 うんこじゃない言語もコンパイラはうんこ言語(お前に言わせるとC言語)でつくられてるけどな Cはうんことかほざくやつ まさかLinuxなんか使ってねえだろな Cがウンコとか言ってる奴に限ってRubyでしか書けないとかいうオチだったら笑えるんだけどな むしろ Ruby で自由にコードを書ける人を尊敬する今日この頃。 最近やってるんだけど、どうしても馴染めない。普通には組めるけど、違和感が残るというか抵抗があるというか。 リフレクションを使う気がなければリフレクション自体がウンコだよ。 ・ソースコードがだだ漏れ ・実行体が無駄に膨らむ(ソースコード情報を含むため) ・リクレクションが必要な用途なら、動的言語でついでに型無しの方が断然楽 GUIとかね。 ウンコと言われ続けたJavaScriptを誰も殺せず、 ついにはElectronとか言い出してデスクトップ側にも進出してきてるだろ。 やれば分かるがGUIに関しては動的型無しHTML(=JavaScript)は最強。 C言語はC言語が目指した範囲での仕様は美しいよ。 ただそこには今後ともリクレクションは必要ないね。 唯一引っかかるのは>>122 か。 >>133 どの辺が? 俺はRuby使いではないが、それよりも酷いとされるJavaScriptには馴染んでしまったから、 ある程度は答えられるかも。 lua等の組込み言語とやり取りする container生成用補助構文群が有ってもいい 関数では前方宣言とか scopeが邪魔して対処しきれないだろうから うまくすれば文字列操作表示も標準libraryから追い出せる pr(test_t, (test_t){.i=999; .s="abc";}); >>134 javaでアノテーションいじり始めるとリフレクションまじ便利で欲しくなるけど、c系にはなくてもいいかなというのも思う。 テバグ目的ならgdbでいいしな。 >>134 規模が大きい場合は型があって静的に検査できるほうが便利だねというのが世間の流れだと思うが TypeScriptとかFlowとか 速度を稼ぐ目的でwasmも今後主流になっていくだろう 巨大ストレージ、OSSが主流な時代にメタデータのサイズやソース隠蔽は気にしなくなったし >>138 > 規模が大きい場合は型があって静的に検査できるほうが便利だねというのが世間の流れだと思うが 違うね。今の流れは「選べる」だ。つまり、 ・型無し言語に型情報を付加し、恩恵を受ける---TypeScript ・型あり言語に型推論やジェネリックを追加し、型情報を記述する煩わしさを回避---C#/C++/Java どっちも出来ることはほぼ同じ。ほぼ全ての言語がここを目指してるでしょ。(Cを除く) 要するにいいとこ取りを目指しているわけで、自然な流れだ。 型があった方が助かるのなら書け、煩わしいだけなら書かなくて済む、という方向に進化しつつある。 なお、GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。 > 速度を稼ぐ目的でwasmも今後主流になっていくだろう ならんと思うし、C使いにとってはなったとしてもああそうですか、でしかないと思うが。 > 巨大ストレージ、OSSが主流な時代にメタデータのサイズやソース隠蔽は気にしなくなったし OSSについては歪んでいて、本来は選べるべきだよ。 JavaScriptのようにソース曝露必須というのは問題ではある。 富豪どころか大富豪プログラミングを自由に出来る時代ではあるが、 何だかんだで速度=バッテリの持ち/快適さなので、実際は、「気にしなくていい環境も増えた」だよ。 とはいえCレベルでのチューニングが必要なこともそうないが。 >・型無し言語に型情報を付加し、恩恵を受ける---TypeScript >・型あり言語に型推論やジェネリックを追加し、型情報を記述する煩わしさを回避---C#/C++/Java 後者は型を明示的に書かなくてもいというだけで最初からすべて型検査してるぞ。 型検査について言えば、動的型付け言語に静的な型検査を導入する流れはあるが逆はない。 動かす前にバグが見つかる仕掛けがちゃんとあるなら 動的型付けでも構わんよ option explicit +中間言語コンパイル,なら使えそうだ >>140 > 型検査について言えば、動的型付け言語に静的な型検査を導入する流れはあるが逆はない。 これは事実としてはその通りだが、理由はこれが型あり言語の正義だからであって、 現実は型検査がウザイだけの時も多いだろ。 C++のtemplateとか、varで書いたら勝手にtemplate化してくれ、という場合も多い。 込み入ったことをやるとコンパイルを通すだけの為に苦労したりするが、 あんなのは完全に時間と手間の無駄だ。 また、他でもよく言われているが、確かに関数ポインタを常用し始めた場合、 型あり『しか出来ない』言語は壮絶にウザイ。どうでもいい型が氾濫するだけだし。 言語として出来る/出来ないではなく、 ユーザーがやりたい時には出来る/やりたくない時には切れる、が正解なんだよ。 型無し言語はこれを認めていて、欠点を修正し始めてる。 型あり言語はこれを認められず、まだ自分たちの正義(型検査は必須)を押し売りしてるだけ。 C(と言うかC++)ではconstがこの状況に近いのではないかな? 通説ではconstは付けるべき、となっているが、俺は付けてない。理由は、 ・そもそも俺はconstで苦労したことがない(必要性を感じない) ・中途半端に付けてると余計に面倒になるだけ ・const_castとか、ただの馬鹿としか思えない なんだが、同様の意見の奴もある程度はいるだろ。 過剰な型検査ってのはあるんだよ。それが人によって異なるってだけで。 やればいいって物ではない。 なんだ?>>139 の「違うね」ってのは現状認識が違うって話じゃなくてあんたの理想と違うってことか? そりゃ正解はあんたにしかわからんわ。 >>147 現状認識も間違っていると思うけど。 日本語が不自由ならさようなら。 そもそも「型検査」が欲しいわけではなくて、静的チェックが欲しいだけなんだよ。 君は最初からずれている。>>141 が正しい。 > コンパイルを通すだけの為に苦労したりするが、 > あんなのは完全に時間と手間の無駄だ。 そうだねえ 自分の考えがはっきりしてなくて筋が通らないのを コンパイラに突っ込まれ、そのたびに右往左往じゃ 下手の考え休むに似・・いや如かずってやつ 「今の流れってこうだよね」 「俺の欲しいものは違う」 会話にならねぇ。 >>150 そうとしか取れないのは君が未熟だからだね。 「流れ」ってのは原因ではなく、大多数が希望した「結果」なんだよ。 君は初心者だから、毎日コード書いている連中が何を求めているのか分からない。 それだけだね。 >>139 ,146 >GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。 見てわかる程度の規模の場合は型無しでもよいだろうね >型検査がウザイだけの時も多いだろ どんな時?C#には動的に型解決するdynamicがあるけどほとんど使わないな COM除けばJSONやXMLの処理で楽するときぐらい?それでも本番用ならちゃんと書くなぁ >どうでもいい型が氾濫 ジェネリックで型指定するだけだから氾濫しなくね? あと、constはプログラマーがミスを防ぐためのものであると同時にコンパイラーへのヒントでもある const修飾されていれば大胆な最適化が可能な場合も多い >>151 俺も>>150 と同じように読めた。 自分の希望を大多数の希望だと決め付けるのは止めろよ。 >>152 > >GUIに関しては型無しでも大して苦労しない。バグっているかどうかは見れば分かるから。 > 見てわかる程度の規模の場合は型無しでもよいだろうね 規模にかかわらず、見ずにチェックするGUIなんて無いだろ。 > どんな時?C#には動的に型解決するdynamicがあるけどほとんど使わないな おー、C#はやはり進んでいるというか、痒いところに手が届いているね。 要するに楽をさせてくれでしかないのだが、ぱっと思いつく遭遇したケースは、 ・callbackでdelegateの型チェックがウザイ。グダグダ言わずにcallbackしてこい。 ・リフレクション時がかなり最悪。(C#なら問題ないが、 VC++2008とかだと、MSDNで型を調べながら型を書くという本末転倒の事態になる) 以下にはJSONガーとか書いてあるけど、JSONをC++で受けたことはないので実感はない。 http://ufcpp.net/study/csharp/sp4_dynamic.html#what 後は型無しだとデタラメなパッチが可能だというのもあるし、俺は常用してるけど、 これ自体はあまり推奨されることではないね。 俺はJavaScriptで型をかかないことに慣れてしまったので、 再びVC++で型を書く時にウザくて仕方ない。 (ただしこれはVC++しかやってない時には全く感じなかった) 要するに型情報は具ではなく、ただのチェック用付加情報でしかないんだよ。 例えれば、当たり前に読める漢字にもいちいち全部ルビを付けている感じか?二度手間がウザイ。 ただし二重チェックをしたい部分もあるので、そういうところは書かせろ、とも思うが。 コンパイラにプログラマが合わせるのではなくて、プログラマにコンパイラが合わせるべき。 > ジェネリックで型指定するだけだから氾濫しなくね? C#は多分そうだね。C#では解決済みかも。 > const修飾されていれば大胆な最適化が可能な場合も多い この説はよく聞くが、具体的にどういうケースよ? >>141 こういうやつってユニットテストしらないのか? Cでも今時は書くだろ 型どうこうで考えるべきは依存関係なんだが 静的型言語はすぐに依存関係ができる そのためにやれ継承だのインタフェースだのデザパタだのとごちゃごちゃ考えなきゃならん しかもデザパタで実現できる疎結合は完全じゃないからね ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる