第22回[最終回]Appendix.3 配列とポインタ、構造体と共用体、makeについて 山森丈範 2007-11-23
第22回[最終回]Appendix.3 配列とポインタ、構造体と共用体、makeについて 山森丈範 2007-11-23
先週、 Hacker News上で興味深い議論が行われました 。テーマは Linux Kernelのコーディングスタイル についてです。 議論の中で私は、 コーディングで垂直方向にそろえるインデントをとるべきか というささやかな聖戦を仕掛けました。私は全面的に賛成です。理由を説明しましょう。 垂直方向にそろえるインデントをとるとは？ 簡単な例を挙げてみます。 int robert_age = 32; int annalouise_age = 25; int bob_age = 250; int dorothy_age = 56; ちょっと見ただけで、「bob_age」がおかしいと分かるでしょう。また、目視であちこち探さなくても、全ての値が整数であることが簡単に確認できます。 この考え方は 一般的に 共有 されているわけではありません。ですので、なぜ 多くの 人たち がこれを有効なスタイルガ
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
Cコンパイラといえばとてつもなく複雑なプログラムというイメージがあります。ところが、このCコンパイラを(サブセットとはいえ)わずか500行ほどのCのソースコードで実現した「CC500」名付けられたプログラムが公開されています。 ソースコードは可読性を維持するためにつけられた空行やコメントを含めると、実際は750行ほどになるそうですが、それでもこれだけコンパクトなソースコードで実行可能なELFバイナリ(Linux用のバイナリ)を生成できるのは興味深いのではないでしょうか。 以下実際にLinuxでコンパイルしてみました。 自己コンパイルできる このコンパイラはC言語のサブセットで、自分自身のソースコードをコンパイルできるところがおもしろいところです。まず「cc500_1」という実行ファイルを生成します。 gcc cc500.c -o cc500_1 生成された実行ファイル「cc500_1」を使
プログラミングをはじめよう いよいよ2010年度がはじまりました。この春からの新入社員や新入学生の方の中には、これからLinuxでプログラミングを始めるという方も多くいると思います[1]。Windowsでプログラミングといえば、Visual Studioのような統合開発環境を使用するのが一般的のようですが、Ubuntuではどうすればよいのでしょうか。 UbuntuはUnixの文化を受け継ぐOSですから、プログラミングのためのツールは豊富に揃っています。しかしそれゆえに「とりあえずこうすればOK」という定石がよくわからないという人も多いかもしれません。 Linuxにおける開発環境は色々ありますが、やはり一番メジャーな統合開発環境といえばEclipseとNetBeansでしょう。しかし今回から3回にわたって、開発環境としてのEmacsを紹介します[2]。 Emacsのインストール Emac
>>（1）よりつづく 前回は単純な実装からマルチスレッド、スレッドプールと順に見て行きました。今回はいよいよepollを使った実装を紹介します。 epoll例- 4epoll.c 多重I/Oすなわち select(2) / poll(2) によるイベントループはマルチスレッドが普及する以前から利用されていました。 select(2) / poll(2) は複数のファイルディスクリプタ（ソケット）を調べ、I/O可能なものを返すシステムコールです。ソケットに対する読み取りはデフォルトではデータがなければブロック（データが到着するまで待つ）しますが、事前にI/O可能かを確認しておけばブロックすることはありません。1システムコールで複数のソケットを調べられる点も重要で、1プロセスで複数のクライアントに並行して対応できるようになります。しかし当然ながら、対象ソケット数の増加に応じて処理量が増えます。
Linuxで共有ライブラリ（*.so）を作るようになったのでちょっと勉強してみた。今までは使うだけだったので、以下のようなことは知っていた。作るときはgccの-sharedオプションを使う。使うときはgccの"-lライブラリ名"でリンクするライブラリを指定する。リンク時のライブラリ探索パスは-Lオプションで指定する。実行時のライブラリ探索パスは/etc/ld.so.confに書いてあるディレクトリ。環境変数LD_LIBRARY_PATHでも指定可能。ライブラリを作るときは、.cから.oを作るときに-fPICをつけるといいらしい。新しくライブラリを入れたときはldconfigするといいらしい。逆に今まであまり知らなかったこと。ほとんどのライブラリはlibhoge.so, libhoge.so.1, libhoge.so.1.1のように3つくらいのファイルがあり、libhoge.soやlibh
プロセスがブロックする要因の一つにファイル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でプログラムを編集した後に、コンソールに戻ってコンパイルの指示を出すという面倒を避けられます。（編集部） そろそろ実用的なことを - Cプログラミング これまで7回にわたってVimの基本的な使い方を解説してきた。これまで紹介してきた操作法を身に付けておけば、かなりの速度でテキストファイルを編集できるようになっているはずだ。Vimを操作する能力は、熟練すればするほど高速になる。スキルアップに費やす対象としては悪くない選択肢だ。今回以降しばらくの間は、より具体的なシーンを想定して、操作方法や、または操作方法をより便利な次元へ引き上げるプラグインについて紹介していく。 Vimといえばやはりプログラミング言語や設定ファイルの編集エディタとして利用することが多い。今回は、C言語のソースコード編集とコンパイル、実行
自作のプログラムから，BIOSの設定を変更する事は可能なのか。 例えばブートデバイス設定やブートシーケンスの設定は， ふつうはPC起動時の「BIOS設定画面」から手動で変更するわけだが， これらの項目を，自作プログラムから書き換える事はできるのか。 （１）BIOSやCMOSなど関連キーワードについて （２）自作プログラムからBIOS/CMOSにアクセスする方法 （３）具体的なサンプルコードと実現方針 （４）結論 （１）BIOSやCMOSなど関連キーワードについて簡単におさらい PCの起動の流れ： ユーザはPCの電源を入れる。 PCのマザーボードに通電する。ここで，マザーボード上には，CPU，ROMまたRAMが設置されている。 ROM内には，BIOSのプログラムが入っている。 ROMとはいえ，フラッシュメモリなので，書き換え可能である。ここの書き換えは，BIOSアップデートを意味する。 RA
neovimは「vimを近代化させよう」というvimのforkです。 https://github.com/neovim/neovim http://news.mynavi.jp/news/2014/02/26/097/ なかなかかっこいいので、現状どのような改修が行われたのかcommitを追いかけてみました TL;DR 開発始まったばっかりなので総Commit数まだ少ない CMake使うようにした ゴミ掃除とサポートしたくない環境の切り捨てをした 実用段階になるには少なくとも半年以上はかかりそう 詳しく Import vim from changeset v5628:c9cad40b4181 ファーストコミット いらなそうなファイルとかマクロとか消したらしい Cmakeにビルドを移植したらしい fork元との差分はなし。あんまり丁寧じゃないね Fix build on OSX/Archl
@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,
最近、Robert Love先生の本を暇な時にダラーと読んでいたりするわけですが、それの中にLinux Kernel内部で使われているLinked Listの実装が書いてあって面白かったので共有。 まず、Linked Listの一個一個のエントリを表すstructを定義します。 struct list_head { struct list_head *next, *prev; }; いやいやいやいや。いかにC力の低い僕でも流石にこれはあきません。騙されませんよ。前後のエントリへのポインタは確かにあるけれども、これにはデータを指すためのポインタがないじゃないの。おじいちゃんまたデータ忘れてきちゃったの？いやあねえ。 おじいちゃんは言った。「それはお前の短見というものじゃ。このLinked Listは以下のコードのようにデータ構造に埋め込んで使うものなんじゃよ。」そしてそれは正しかった。 st
当サイトは、UNIX/Linuxにてよく使用されるコマンド／ツールの使用例や言語の入門やコード事例を掲載しております。 深い理解は求めずに、手っ取り早く使えるように、使用例(サンプル)を中心にしています。 情報の正確さには注意を払っておりますが、誤りや適切でない記述を掲載してしまうかもしれません。 当サイトの情報をご利用いただく際は、どうか、ご自身で十分検証を行ってください。 なお、当サイトのをご利用になられて発生した損害については、当方は一切責任を負いかねますので、あらかじめご了承願います。 また、掲載内容についてのご質問はご遠慮願います。
Android は Linux の一種でもあり、ARM で動く Linux 向けのC言語で書かれたライブラリの多くが動きます。（多少違うので、動かない場合もあり）。ただし、ビルド方法が暗黙の了解事項になってたりして、Android NDK にちゃんと書かれていなかったりするので、ここにまとめます！ 以下、架空の libhoge をビルドすることとします。 ビルド対象は一般的に静的ライブラリ (.a) ファイルにしておくと吉です。自分で使う際は、自分の Android.mk に以下の物を追加します。 LOCAL_CFLAGS に -Ihoge-1.0/include みたいのを追加 LOCAL_LDLIBS に -Lhoge-1.0-android-build/$(TARGET_ARCH_ABI) と -l hoge を追加 ライブラリをビルドしてできた libhoge.a はこのフォルダに
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp： 本: ふつうのLinuxプログラミング Linuxの仕組みから学べるgccプログラミングの王道
