2016年、C言語はどう書くべきか (前編) | POSTD

(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり

[uehaj]

「C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです」

[kazuhooku]

間違いが多いし https://github.com/Keith-S-Thompson/how-to-c-response/blob/master/README.md 読むべき

[Nnwww]

これ原文の方だと批評の記事も出てるんでそっちも一緒に読んだ方が良いですよ

[nabe1121sir]

C言語で開発せざるを得ないのって、過去の資産に対するメンテナンスがほとんどだと思う。ので、こんな新しいデータ型なんて導入したら余計詰むんじゃね？

[junglejungle]

カーネル読めなかったら問題あったとき解決できないだろ。ほとんどのプログラミング言語はCで開発されているし、IoTでC言語は盛り返している。過去の遺物扱いすんな。「C言語を使うな」で喜んでるWeb屋はこれだから。

[shifumin]

「C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです」まで読んだ。

[kmaebashi]

不同意。http://bit.ly/1QmRwQx OSや組み込みとかでビット数を強く意識する必要があるならともかく、アプリケーションプログラムなら、ビット数などという低レベルな概念をソース全体にばらまくべきではないと思う。

[kuenishi]

正論だけどlibcとかposixとかがこれに合わせてくれないと無理

[mohno]

「もし避けられるならC言語を使うな」は分かるが、それはつまり避けられない状況を考えたら（既存の資産とか）、ここに書いてあるようなことは守れないんじゃないだろうか、という気がしてならない。てか、知らんぞw

[mattn]

変わらなきゃいけなかったのに utf-8 文字列にプレフィックスが付いちゃったのには残念感が否めない。

[takeg]

これはE

[yarumato]

“2011年以後のC言語の標準C11では、char、int、short、long、unsignedなどの型を使わず、#include <stdint.h>と記述し標準データ型 int8_t,..uint64_t を使用するべき。charはもう使わない。unsigned 使わない。”

[mingos]

データ型はstdint.hをインクルードして標準データ型を使うべき。

[the48]

大変為になる

[yatmsu]

“C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです。”

[taki0313]

2016年ではCを使わない，じゃないのか（適当）

[atotto]

Go〜！

[vanbraam]

コンパイラーのオプションは参考になった;型も大分変わってて,プラットフォームの解釈で差分が出にくくなってる.既存のライブラリーを使う時もこれ使っていいのであればだいぶ問題を減らせそう

[kasumani]

2016年、C言語はどう書くべきか (前編) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング

[babydaemons]

cl.exeじゃないコンパイラを使いたい。。。

[koudaiii]

だいぶ変わっててびっくりした。

[kenjiro_n]

レガシーとの連続性、いやレガシーそのものを扱っている人間には勉強にはなったが俺のこの数年間を返せと言いたくなるような記事。

[itouhiro]

「char、int、short、long、unsignedの型を使うのは誤り」「標準データ型（uint8_tなど）を使用するべき」「charの使用を唯一許されるのはAPIと読み取り専用文字列」「ポインタの計算に使う正しい型はuintptr_t」

[ttakezawa]

intやcharが誤りというのは言い過ぎなような。末尾のhow-to-c-responseとかいろいろ読んだほうがよさそう

[sugawara1991]

わかるけど、組み込みにしろドライバにせよ、C使うときは対象の環境に合わせた定義込みだしなぁ

[murasaki11]

「もし避けられるならC言語を使うな」

[tamakoron]

2016年、C言語はどう書くべきか (前編)

[kirakking]

反論のほうに目を通してきたけど、「それヘッダがちがいまっせ」から「厳密に言えば at least と exactly の違いが有る」、「完璧に間違っている」までリファレンスで殴ってた。

[masterq]

いまどきのC言語。参考になる

[belgianbeer]

最近知りたかったことがどっさり書いてある

[riocampos2]

はてブみると「原文には批評記事載ってる」とあるので、判断はひとまず後編が訳されるのを待ってからにする。｜2016年、C言語はどう書くべきか (前編) | プログラミング | POSTD

[mas-higa]

ついに int を手放すときがきたか

[ooblog]

#C言語 「charはもう使わない~uint8_t~C11ではネイティブでユニコード~64ビットのシステムでuint_fast16_tを要求するとuint64_t~標準データ型を使用するべき」

[shag]

ルール1だけであれば人類はもっと幸せだっただろう案件

[zyzy]

Rustと比較するために、去年くらいに興味本位で今のCの書き方調べて、昔に比べて結構変わっててびっくりした記憶。何だかんだで進化してるんだよな、Cなりに。

[nilab]

2016年、C言語はどう書くべきか (前編) | プログラミング | POSTD

[hiroshe]

「C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです。」 あぁ、よかった。

[aniyan53]

C言語の第1のルールは、「もし避けられるならC言語を使うな」ということです。C言語の開発では「80年代90年代に学んだ事柄」に留まろうという気持ちを捨てなくはなりません。

[you21979]

昔のC言語は型が曖昧だったからなぁ。intとかchar型が不満だった。