2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
私がコーディングで垂直方向にそろえるインデントをとる理由 | POSTD
先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ
連載：Cプログラミング入門｜gihyo.jp … 技術評論社
第22回 [最終回]Appendix.3 配列とポインタ、構造体と共用体、makeについて 配列 ポインタ 関数の呼び出し 構造体 共用体 makeコマンドを単独で使う 2007年11月23日 第21回 Appendix 2 プリプロセッサ関連の記述 関数とマクロ関数 コメントの書き方 条件コンパイル 2007年11月9日 第20回 Appendix 1 コマンドラインの引数 main()の引数 ファイル名を指定して開く 2007年10月26日 第19回 Chapter7 フィルタコマンドを作ろう フィルタコマンドとは 簡易catコマンドを作ろう 小文字を大文字に変換するフィルタ 2007年10月12日 第18回 Chapter6 forとwhileで繰り返し(2) breakとcontinue for文で無限ループ do while文もある 2007年9月28日 第17回 Chapter
CC500: a tiny self-hosting C compiler
Introduction I wrote this tiny compiler, which translates a subset of C into x86 machine code, for fun. It has no use, unless it counts as educational. I called it CC500 because I initally guessed it would take about 500 lines. It turned out to be about 600 lines even without the comments and blank lines. With the comments and blank lines it has about 750 lines. It could be made shorter, but I wan
わずか500行のCソースコードで作られたCコンパイラ「CC500」 | ソフトアンテナ
Cコンパイラといえばとてつもなく複雑なプログラムというイメージがあります。ところが、このCコンパイラを(サブセットとはいえ)わずか500行ほどのCのソースコードで実現した「CC500」名付けられたプログラムが公開されています。 ソースコードは可読性を維持するためにつけられた空行やコメントを含めると、実際は750行ほどになるそうですが、それでもこれだけコンパクトなソースコードで実行可能なELFバイナリ(Linux用のバイナリ)を生成できるのは興味深いのではないでしょうか。 以下実際にLinuxでコンパイルしてみました。 自己コンパイルできる このコンパイラはC言語のサブセットで、自分自身のソースコードをコンパイルできるところがおもしろいところです。まず「cc500_1」という実行ファイルを生成します。 gcc cc500.c -o cc500_1 生成された実行ファイル「cc500_1」を使
第116回 UbuntuとEmacsでプログラミングをはじめよう（前編） | gihyo.jp
プログラミングをはじめよう いよいよ2010年度がはじまりました。この春からの新入社員や新入学生の方の中には、これからLinuxでプログラミングを始めるという方も多くいると思います[1]。Windowsでプログラミングといえば、Visual Studioのような統合開発環境を使用するのが一般的のようですが、Ubuntuではどうすればよいのでしょうか。 UbuntuはUnixの文化を受け継ぐOSですから、プログラミングのためのツールは豊富に揃っています。しかしそれゆえに「とりあえずこうすればOK」という定石がよくわからないという人も多いかもしれません。 Linuxにおける開発環境は色々ありますが、やはり一番メジャーな統合開発環境といえばEclipseとNetBeansでしょう。しかし今回から3回にわたって、開発環境としてのEmacsを紹介します[2]。 Emacsのインストール Emac
バッファキャッシュとAIO（1）
プロセスがブロックする要因の一つにファイルI/Oがあります。これを同期I/Oと言いますが、POSIXではAIO（非同期 I/O、Asynchronous I/O）も定義しており、I/O中でもプロセスがブロックせず他の処理を進められるようになります。 本記事ではバッファキャッシュからファイル I/Oを解説し、Linuxのio_submit(2)を用いたPOSIX準拠のAIOライブラリを試作してみます。 ファイルI/Oとバッファキャッシュ io_submit(2)ではDirect I/Oを用いますが、ライブラリの試作へ進む前にまずファイルI/Oのバッファ（バッファキャッシュ）について整理します。実は単にバッファと言ってしまうと誤解される場面が多くあり、例えばプログラミング入門一般としてファイルI/Oを取り上げる際には、 CPUの動作は速い。ディスクの動作は遅い。 両者の間に速度差を緩和する緩衝
Vimをプログラム開発環境にしてしまおう
今回から、Vimをプログラム開発環境にしてしまう方法を解説します。これができれば、Vimでプログラムを編集した後に、コンソールに戻ってコンパイルの指示を出すという面倒を避けられます。（編集部） そろそろ実用的なことを - Cプログラミング これまで7回にわたってVimの基本的な使い方を解説してきた。これまで紹介してきた操作法を身に付けておけば、かなりの速度でテキストファイルを編集できるようになっているはずだ。Vimを操作する能力は、熟練すればするほど高速になる。スキルアップに費やす対象としては悪くない選択肢だ。今回以降しばらくの間は、より具体的なシーンを想定して、操作方法や、または操作方法をより便利な次元へ引き上げるプラグインについて紹介していく。 Vimといえばやはりプログラミング言語や設定ファイルの編集エディタとして利用することが多い。今回は、C言語のソースコード編集とコンパイル、実行
malloc ライブラリのメモリ管理構造 | 技術文書 | 技術情報 | VA Linux Systems Japan株式会社
プログラミング言語 malloc(3)のメモリ管理構造 2007/11/30 技術本部 クラウド基盤エキスパート 角馬 文彦 この記事の目次 malloc()といえばＣ言語ではお馴染みのライブラリで、最も良く使用されるライブラリの一つです。しかしその分だけ何らかの不具合を経験した人も多いのではないでしょうか。本書ではmalloc()、free()で確保、解放されるメモリリソースが内部的にどのように管理されているかを説明していきます。mallocライブラリの仕様を理解する事で、ライブラリ使用時に何らかの不具合が発生した際の手助けになればと思います。 ここではLinuxディストリビューションで標準的に使用されているglibcのmallocライブラリを扱います。今回の調査では次の環境を使用しています。 ディストリビューション :Debian sarge パッケージバージョン :glibc-2.
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
アセンブリ読んだら負けかなと思ってる - 誰かの役に立てばいいブログ
子供のころからできるだけ手抜きして成果を挙げることだけは長けている山本です。 今回は、C/C++ で作ったプログラムが運用中にクラッシュするときのデバッグ方法のお話しです。 開発中のデバッグは gdb などでソース追いながらデバッグできますが、運用中ですと strip していたり最適化していたりしてデバッグが難しくなります。 そもそも、いきなりクラッシュすると情報が残らずに困ってしまいます。そんなときどうするか。 Step1. スタックトレースを出力する こんな関数を用意しましょう。Linux 以外の人はそれなりに実装してください。 #include <execinfo.h> #include <unistd.h> void dump_stack() { void* bt[100]; int n = backtrace(bt, 100); backtrace_symbols_fd(bt,
本の虫: 記録からみるLinus TorvalsのC++観
On Wed, 5 Sep 2007, Dmitry Kakurin wrote: > > Gitのソースコードを始めてみた時、2つのことが頭にひっかかった。 > 1. C++じゃなくて純粋なC。理由は不明。移植性とか言わないでよ。 > クソだ。 クソまみれなのはオメーの方だ。 C++は悲惨な言語だ。しかも、少なからぬ数のプログラマーが使っていて、完全無欠のどうしようもないクソを生成するのがめちゃめちゃ簡単になっているという点で、よけいに悲惨だ。マジで、Cを選択する理由が「何もなかった」としてもだ、C++プログラマー避けになるというだけで、Cを使う大義名分になる。 つまりだ：Cの選択は唯一のまともな選択なんだよ。Miles Baderがふざけて、「いやがらせによる追い返し目的」なんていってたが、実際のところ正しい。俺の出した結論では、プロジェクトにCよりC++を使いたがるプログラマーは、む
ネットワークプログラミングの基礎知識
ネットワークプログラミングの基礎知識 ここでは IP アドレスやポート番号、クライアントとサーバの役割などを説明し、 perl・C言語・Java などでソケット (Socket) を使った HTTP クライアントや POP3 クライアント、簡単なサーバを作成してみます。 要はネットワークプログラミングをやってみよう、ということです。 このページのサンプルプログラムは、RFC などの規格に準拠した「正しい」プログラムではありません。 また、全体的にエラー処理が不十分です (今後改善する予定です)。 あくまでも概要を理解するためのサンプルととらえてください。 もし本気でしっかりとしたクライアントやサーバを書きたいなら、このページを読んだ上で、 さらに RFC を熟読し、そして wget・Apache・ftp コマンドなどのソースを参考にしてください。 このページに間違いを見付けたら、掲示板 で
Vimをプログラム開発環境にしてしまおう
今回から、Vimをプログラム開発環境にしてしまう方法を解説します。これができれば、Vimでプログラムを編集した後に、コンソールに戻ってコンパイルの指示を出すという面倒を避けられます。（編集部） そろそろ実用的なことを - Cプログラミング これまで7回にわたってVimの基本的な使い方を解説してきた。これまで紹介してきた操作法を身に付けておけば、かなりの速度でテキストファイルを編集できるようになっているはずだ。Vimを操作する能力は、熟練すればするほど高速になる。スキルアップに費やす対象としては悪くない選択肢だ。今回以降しばらくの間は、より具体的なシーンを想定して、操作方法や、または操作方法をより便利な次元へ引き上げるプラグインについて紹介していく。 Vimといえばやはりプログラミング言語や設定ファイルの編集エディタとして利用することが多い。今回は、C言語のソースコード編集とコンパイル、実行
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp： 本: ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道
Inside memory management