C言語なら俺に聞け 153
レス数が950を超えています。1000を超えると書き込みができなくなります。
BNFで思い出したが
enum { a } func(void) { return a; }
この文法使い道ないよな >>714
エイリアスの否定とはいただけない
直値だけの糞コードはゴメンだわ
意味によって0とNULLは書き分けるよ >>855
その書き分けに意味はあるのでしょうか？ >>856
お前にとっては意味がない。
俺や俺以外の書き分けたい人には意味がある。
それだけだから気にしなくていいぞ。 やたら長いコードの中で
it = &a;
*a = 0;
it = 0;
a = 0;
とか書かれたら混乱するだろ。
あ、でも屑はハンガリー人なんだっけ？ >>858
混乱するから数値のゼロもdefineしなさい >>825,846
自分ならこんな感じで書く、程度のものですが思うけど良かったらどうぞ
https://pastebin.com/idm94WiU
別の機能を追加する必要とか出てきたとき、
ジャンケン自体を関数化してあげたほうがmain()関数内がゴチャゴチャしなくて良いかなと思って書きました。 typedef char String[1024];
とtypedefしてるのはたしかどこかの教科書の流儀だったはずだ
最近その話題を見かけた あいこでの再戦と、もう一回じゃんけんするのは、
目的が違うんだから別ロジックにすべき。 同じ処理を共通化する
今後異なる可能性のある処理をあらかじめ分けておく
いろんな設計思想がある >>864
配列のtypedefって代入で問題にならんのかな
今のCの仕様追ってないけど昔は構文エラーになるから構造体に入れる必要があった >>825
これは危険なので普通はやらない。
scanf("%s", nextStr); >>868
jmp_bufは配列のtypedefだよ >>871
そういやそうだね
ローカルに作って環境保存にmemcpyした覚えないから代入できるのか
色々忘れてるわ ポインタを受け取る関数先頭では必ずnullチェックを行うコーティングルールが有るのですが
malloc失敗したポインタをそのまま渡した時ぐらいしか使い道が思い付きません… freeしたときに0入れるルールもあるんじゃないのそれ >>873
杓子定規に適用したら形だけの無駄なチェック処理の典型だね。
上位レイヤとの境界のような意味のあるところだけなら現実的だけども。 仕様としてnullを許可する関数ではチェック不要としているのかあるいは一律に
null渡し禁止としているのかで評価は変わりそうだが。 get_state()みたいな関数があって失敗時はnullを返す。それを知らずに別の関数に戻り値を直接渡してしまったとか、nullが誤って渡されるケースなんていくらでもあると思うが。
873が超天才でそんなミスは絶対ありえないとしても、他人のコードやドキュメントが間違ってる可能性もある Player*とEnemy*を取るRPGのバトル関数で
どちらかが死んでたらplayer->attack()関数は盛大に失敗する
この時の当該playerは消滅したわけでは無いが
enemyはメモリ上から消えている
ついでにこのattack関数が実は関数ポインタに付けられたプレイヤーのスキルだった場合、
attackがカラッポだと、徒手空拳になるか防御するか何もしないか、何故か敵味方全員が即死していきなりエンディングが始まるかのどれかになる 安全性を取るならいついかなる時もNULLチェックは行うべき
だがそもそもパフォーマンス至上主義だから
Cという太古の言語を危険を冒してまで使っているということを考えると微妙
パフォーマンスが重要でないならCを使っていることからして論外 成否を含んだtupleを渡し実行時に判別、式全体を読み飛ばす粒度の小さい隠れた分岐構文みたいなの有ればいいのにねー
成否要素だけの反転は !!tulpevalue みたいな感じで
c言語の仕事じゃないだろうしそもそもtupleなんて持ってないし
うんこマが技巧駆使してわけわからんコード書くツールになるだけかもしれんし弊害いろいろ思いつくけど >>878
召喚された悪魔が鼻から出てきて世界滅亡エンドも追加しといて。 >>879
Assertマクロとかでいいだろ
テストとかで引っ掛けるという実利に加えて「nullなんて渡すんじゃねーよボケ」と言うのを表明する意味もあるし nullに意味を持たせないプログラムなら、
null checkしないと落ちる環境ならする意味ないんじゃね Release build だと assert 消えるって知らない人意外と多いんですね >>884
消えるって知ってるからassertにしろっていう意見なんだろう その意見を完全にスルーしてコメントしてる人がいるよね assertを本番環境に持ち込むべきと
主張する痛いやつが昔いたが
奴は今どうしてるかな C++11 の static_assert は便利なんですけれどもね…これ、C に入らないかな…
assert も static_assert と同じ用途・考え方で使うべきものかと思いますね Cにもstatic_assertか
考えたこともなかったが
確かにあったらよさそうだな
もういじるなってのが
俺の基本だが
追加に賛成できる珍しい例だ >>892
> assertを本番環境に持ち込むべきと
> 主張する痛いやつが昔いたが
> 奴は今どうしてるかな
本番用はいちいちassert外してるのか？w >>895
assert は Debug ビルドのときだけチェックを行う実装になってるのが普通 >>897
だから>>892が意味不明なんだけどw >>898
リリースビルドで有効な assert を用意するだけだろ
何が不思議なの？ 本番環境に持ち込むべき
影響出ないんだから
こういうことでは 深いところで拾ったエラーを浅層に戻して対応する必要がなく「ダメよ」と述べ落ち許されるプログラムならば
assert残すのも有りよね
実際#ifdef DEBUGで包んでるだけだし
imagemagickなんかも引数チェックを通った後の個々パラメータ内で不整合出たらassertでメッセージ流して落ちるし >>900
assert が発動してアプリが止まるのは終わり方として最悪だとおもいますよ
もし assert が発動する可能性があるんだったら assert ではなくて、きちんとしたエラー処理を記述するべきなのでは？
assert って辞書をみると「断言」「主張」「出しゃばり」くらいの強い意味ですね
私は assert はコメントの一種一様態として使います＝>>893 >>899
えっ？
>>892が正しいという主張？
まあ>>901みたいな考え方もあるだろうけどさ >>901
assertに引っ掛かったときの挙動は置いとくとしても、assertの処理内容や頻度によっては実行時コストが問題になる可能性も無くはないから、単純にやってよしとはならないと思うぞ。 効率厨はログ出力を見れるGNUemacsのeshell辺りででもwindowsプログラム立ち上げてみ？
プロプラ、オープンソースに関係なく大半のリリースビルドが膨大な出力を出しっパになってる現状に絶望するだろうから >>905
その環境で動かすと、プリプロセッサ段階で消去されているはずのデバッグ文実行結果が見れる様になるんですか？ >>905
処理内容や頻度によって実行時コストが問題になる可能性があると言っただけで効率厨扱いとはw
既存プログラムでログを大量に出しているからと反論しているが、だからそれがどうしたというのだ？ ログを出しても性能的に問題ない範囲、頻度、量で出しているだけだろう。 >>907
assertion は「コメントの一種」という私の立場では、重い assertion の罪は軽い、許容できると感じています 組み込みだとタイミング込みで評価するから
ビルドを切り替えられないんだよね
assertはログだけ出すようにしてるが
ウォッチドッグを効かすってのもありかな
起こり得ないところで使うってのはその通り ロケット打ち上げ２秒後でassert出ても意味が無いな
そのまま大爆発だ
衝突する0.5秒前でassert出ても意味が無い
時速90kmでそのまま衝突だ uint64_t を配列の添え字に使えるかどうかって何か規格はありますか？
手元の環境は unsigned int のようなんですが、gcc/ming32-x64 >>911 何を見て「unsigned int のよう」と言っているの？ >>911
ISO/IEC 9899:2011 (E)
6.5.2.1 Array subscripting
1 One of the expressions shall have type "pointer to complete object type", the other
expression shall have integer type, and the result has type "type".
7.19 Common definitions <stddef.h>
size_t
which is the unsigned integer type of the result of the sizeof operator;
どこにもunsigned intに限定するとは書いてねえぞ
unsigned integerと書いてあるのが
おまえはunsigned intに見えるのか？ >>912-914
コメントありがとうございます
uint64_t と int をいいかげんにチャンポンに使っていたための祟りに襲われてしまっているところでして…
a[i] = *(a + i)
を考えれば、i が int = int32_t, であろうと uint64_t であろうと、うまくやってくれると予想できますね >>916
それを言うならi[a]だ
ドヤるなら動作確認くらいしてからにしろ
そもそも後置演算子の[]が[a]iなわけねえだろ STLの配列の添え字は、std::size_tと同じ範囲が使えるように思う。
このstd::size_tには長さの制約は多分ない。
常識的に考えて、32ビットのプログラムで64ビットの配列を使うことはあまり現実的ではない。
なので、std::size_tの長さはNビットプログラムにフィットするようにコンパイル時にスイッチされる。はず。 思うんじゃなく確認しろ、多分とか寝言ぬかしてねえで
N4713
26.2.1 General container requirements
Table 83 ? Container requirements
X::size_type
size_type can represent any non-negative value of difference_type
26.3.8.1 Class template deque overview
// element access
reference operator[](size_type n);
const_reference operator[](size_type n) const; 具体的な規格の文面を引用して示してくれるのは有難いことでしょ。
手元にPDFとかで持ってても場所を見つけるのが苦労で諦めることが多いし。
size_type can represent any non-negative value of difference_type
の部分を見ると size_t の大きさは difference_type の大きさに依存する、
少なくとも difference_type の正の範囲より広い、で合ってるかな。
ならば difference_type の範囲はどうなってるの？ って具合に
疑問の先が移動するね。答えに近づいたけれど到達はしてない感じ。 俺は符号付のほうが好きだな
符号なしって扱いがめんどくさい だがptrdiff_tは符号付きだ
絶対アドレスに符号はなくても
オフセットには符号がある
配列の添え字はオフセットなわけだが
それでもsize_tであるべきか？ BSTRのように、ときどき境界より前を参照したいことはあるかな free()とかマイナスオフセットなしでどうやって実装するんだよ、とかね いつになるか激的アーキテクチャの進化でも迎えない限り
64bitでmsbまで使い切る正数アドレスなんて無いから
相対はヌルチェック＋自動整数変換に頼っときゃいいんじゃね
fseek/off_tはなんかもやもや放置気味？誰が完全な解決をもたらすのか 俺はCからプログラミング言語は学んだが、Cから入って正解だったな
あの苦難の道を思えばどれも大したことはない
C++とRustを除けば なんだっけそれ
どっかで聞いたことあるんだが思い出せない >>935
熱素やエーテルみたいな架空の物質モデル論のひとつ >>936
アニメで引用されてた気がする
エヴァだっけ？ディラックの海ってリツコが言ってたような 2019年に成長したプログラミング言語ランキング、第1位は？ 2020/01/10 09:18 後藤大地
https://news.mynavi.jp/article/20200110-952052/
TIOBE Softwareがこのほど、2019年に最もインデックス値を伸ばしたC言語が2019年のプログラミング
言語・オブ・ザ・イヤーに輝いたと伝えた。第2位はC#で、これにPythonとSwiftが続いている。
C言語のインデックス値が伸びた理由として、IoTおよび小型のインテリジェントデバイスにおいて需要が
高いためだという。C言語は短時間で習得が可能な上、すべてのプロセッサにおいてCコンパイラを利用
できる。TIOBE Softwareは、こうした状況がC言語のインデックス値上昇を招いたのではないかと分析
している。
発表された2019年におけるインデックス増加率と順位は次のとおり。[順位]プログラミング言語(増加率)
[1]C(+2.4%)、[2]C#(+2.1%)、[3]Python(+1.4%)、[4]Swift(+0.6%)、
2019年のプログラミング言語・オブ・ザ・イヤーは、2018年に引き続きPythonが受賞するだろうと考え
られていた。これは、Pythonが2018年に入ってから長期にわたって増加傾向を維持しているためだ。
しかし、2019年はC言語の増加率がPythonを超えて1位となった。C言語は2016年に一気にインデッ
クス値を下落させており、2017年後半から逆に増加に転じている。ずでに減少以前の水準まで戻って
きており、今後も同様のペースで増加を続けるかどうかはわからない。
仮に、今後も同様のペースでC言語の増加傾向が続いた場合、JavaとC言語のポジションが逆転して
C言語が首位になる月が出てくる可能性もある。しかし、過去の動向として、JavaとC言語は推移が同調
する傾向が強く、Javaが第1位でCが第2位という順位のまま推移する可能性もある。(中略)
TIOBE Programming Community Index (PCI)は、複数の検索エンジンの検索結果から、対象となる
プログラミング言語がどれだけ話題になっているかをインデックス化したもの。2020年1月におけるイン
デックスは次のとおり。
1月TIOBE Programming Community Index / 円グラフ
https://news.mynavi.jp/article/20200110-952052/images/002.jpg Cの文法や標準ライブラリがコンパクトだし覚えるべき概念も少ないのは間違いない オブジェクト指向とポインタならポインタの方がラク
それにメモリに沿ってるので分かり易い ポインタとオブジェクト指向は別物だからな
そもそも比べるのがおかしい 考えようによっては、ポインタとメモリの関係を理解してしまえば、
Cほど単純な言語とその標準ライブラリも他にないからなぁ まあ組込みだとCでいいと思うけどテンプレとかも使いたいからオラはベターCだな ま、抽象度が低いと覚えることは少ないんだよ。
論理回路は覚えることが超少ない。 覚えることが少ないというか物理的で直感的だからわかりやすい
クラスとか言われても初心者には「？」だし C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。
C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:
- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)
- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。
言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。 レス数が950を超えています。1000を超えると書き込みができなくなります。
