Why Is SQLite Coded In C
Note: Sections 2.0 and 3.0 of this article were added in response to comments on Hacker News and Reddit. Since its inception on 2000-05-29, SQLite has been implemented in generic C. C was and continues to be the best language for implementing a software library like SQLite. There are no plans to recode SQLite in any other programming language at this time. The reasons why C is the best language to
Using WebAssembly threads from C, C++ and Rust
Learn how to bring multithreaded applications written in other languages to WebAssembly. WebAssembly threads support is one of the most important performance additions to WebAssembly. It allows you to either run parts of your code in parallel on separate cores, or the same code over independent parts of the input data, scaling it to as many cores as the user has and significantly reducing the over
なぜCを学ぶべきなのか - 立命館大学情報理工学部セキュリティ・ネットワークコース プログラミング言語サポートページ
プログラミング言語としてのCは、初学者にとっては難しい言語であるのは確かです。中には、初心者が学ぶべき言語ではないと言い出す人もいます。ですが、私たちセキュリティ・ネットワークコースの教員は、我々のコースの学生は早期にCを学ぶべきであると考え、このカリキュラムを設定しています。以下に理由を列挙します。 Cはコンピュータの構造に深く根ざした言語なので、コンピュータそのものの学習を同時に進めることで、相互の理解が深まると考えています。例えば主記憶(メモリ)上にプログラムとデータの双方が置かれるフォン・ノイマンアーキテクチャや、メモリ上のデータ配置の問題、エンディアンの問題などを直接感じられるのはCならではだと思います。 CはOSや、コンパイラなどの言語処理系、組み込み機器などで広く使われており、その構造や動作と深く関わっているため、セキュリティとネットワークの理解のために欠かせないからです。
ERR30-C. 関数を呼び出す前に errno をゼロに初期化し、関数の異常終了時にのみ errno を参照する
errno の値を設定するかどうか規定されていないライブラリ関数 C 言語規格では、一部の関数について errno をどう扱うかを規定していない。例えば、setlocale() 関数はエラー発生時に null ポインタを返すが、errno を設定する保証はない。 これらの関数を呼び出した後、errno の値のみに依存してエラーの発生を判断してはならない。関数は errno の値を変更したかもしれないが、errno がエラーの状態を適切に示しているという保証はない。 他の規格で動作が規定されているライブラリ関数 一部の関数は、他の規格で errno の扱いに関して異なる挙動が規定されている。一例として fopen() がある。fopen() はエラーに遭遇すると null ポインタを返すが、このときの errno の扱いについて C 言語規格では何も言及していない。しかし POSIX.1 で
Cのエラーメッセージ出力に関数名や行番号を付加する - 百日半狂乱
二十五日半狂乱、5日目(の分)の記事 C言語における関数のエラーハンドリングには戻り値およびerrnoを使うが、自分が読んだ文法書などのサンプルコードではエラーが起こった場合の処理が、大体がperror("fopen"); exit(1);のような感じのもので、まぁ小さいサンプルコードをいくつも書いていたうちはこれでも良かった． だけど、ある程度以上の規模のアプリケーションを書き始めて、コードがそれなりに大きくなってくると一体どこのエラーなのか一目でわからなくなってくる. エラーメッセージを自由に設定して、関数名や行番号も表示したい．それに何度も書くのでできるならお手軽に書きたい. そんな事情で、一年前くらい前に以下のようなエラーメッセージ用の関数を作った.コンパイラはgccを使用する. 改めて見ると現在時刻は完全に蛇足な感じがするが、まぁ割と重宝している． 上記サンプルは実行すると、現在
C++11で覚醒した共用体の話
はじめに KMC 2回生のhatsusatoです。コミケまでもう1週間もないんですね1。27日まで授業があるとか正気の沙汰じゃない。 この記事は KMC アドベントカレンダー 2013 の 23 日目の記事です。昨日の記事は DtYaZsK 君の C++11超入門 でした。 今日は昨日に引き続いてC++11に関するお話です。 C++11で覚醒した共用体の話 共用体はたいていのC言語の入門書に載っている（と思う）ので、C言語をひと通り勉強した人なら共用体を知っていると思います。共用体はC言語の持つ低レベルなメモリ操作能力の一翼を担っています。しかし、共用体を実際に利用することは非常に稀でしょう。 実はこの共用体が、C++11での仕様変更によって生まれ変わりました。今回はそんな共用体にスポットライトを当ててみます。 共用体の基本 まず、C++11で共用体がどうなったのかを見る前に、これまでの共
【C言語】引数なしの関数には void を書いた方がよいという話 - 0x19f (Shinya Kato) の日報
C言語で引数なしの関数を書くときに void を書かないのと書くのとで挙動が違うなんて話を聞いたことはないでしょうか？ つまり void func() {} と void func(void) {} で挙動が違うという話ですね。 自分も話だけ聞いたことがあったものの2つがどう違うのかはわかっていなかったため、C言語の規格を読みながら何が違うのかを調べてみました。 結果だけ述べると、この2つの書き方は同じように見えて実は明確な違いがあり、引数がない関数を定義/宣言する場合には後者を使うのが適切です。 とは言え、2つの書き方で違いがあるとかほんとかよ？と思う方もいると思うので、まずはこの二つがどう違うのか見ていきましょう。 2つの関数の書き方の違い 早速ですが、以下のプログラムを見てみましょう。 // func_empty.c void func() {} int main(void) { f
void でキャストすることで "unused" の警告を回避する - Secret Garden(Instrumental)
元々は C言語?で使われているようなハックらしいのですが、知らなかったので覚書。 さて、例えば次のように関数の引数を assert チェックしてる関数があるとします。 void func(int value){ assert(value == 42); } この場合、デバッグビルドでは問題ないんですがリリースビルドでは『assert で参照してる value が使用されていない』とコンパイラが判断して、 warning: unused parameter 'value' [-Wunused-parameter] という風な警告を出す可能性があります。 このような場合、次のように void でキャストして回避することが可能です。 void func(int value){ (void)value; assert(value == 42); } たまに (void)xxx; しているコードを見
ERR04-C. プログラムの適切な終了方法を選択する
ERR04-C. プログラムの適切な終了方法を選択する 範囲外エラーなど、いくつかのエラーはユーザの誤入力が原因で生じる場合がある。通常、対話型プログラムはこのようなエラーに対処するため、入力を拒否し、受け入れ可能な値の入力をユーザに促す。サーバはクライアントにエラーを示すことにより無効なユーザ入力を拒否し、同時にそれ例外のクライアントの有効な要求に対するサービスは続行する。揮発性ストレージに保存されたユーザデータの損失を防止することにより、少なくとも、メモリ残量低下(ディスクスペースの状態)などのリソースの不足に適切に対処するには、堅牢なプログラムを準備する必要がある。対話型プログラムを使用すると、ユーザはデータを代替メディアに保存でき、ネットワークサーバはスループットを落としたりサービス品質を低下させたりして対応できる。ただし、不確実な状態での実行を続行することによるリスクデータの破壊
インクルードガードとpragma once - にゃははー
C++ Advent Calendar 2015の5日目です。 前C++時代から近代C++に至るまで、ヘッダファイルの重複インクルード排除のために通称インクルードガードというものが使われてきました。 #ifndef YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H #define YOUR_VERY_VERY_AWESOME_LlBRARY_HEADER_H #endif // YOUR_VERY_VERY_AWESOME_LIBRARY_HEADER_H しかしこれはファイルの前後に書かないといけないという制約や、他のヘッダとトークン列が一致してしまうと意図せずヘッダがインクルードされないという問題がありました。 これに対してたった1行で書いて終わりの#pragma onceは、標準化を求める声も多く、目的が明確で、実装もあるにも関わらず、標準に入る気配すら
Big Sky :: clangd を使う時に便利なコマンド compiledb
先日、Go Advent Calendar の記事の中で Language Server について書きました。 Big Sky :: gocode やめます(そして Language Server へ) はじめに まず始めに言っておかなければなりません。 gocode 今まで本当にありがとう この記事は、Go 言語歴10年になる僕がこれまで愛用してきた Go 言語のコード補完ソフトウェア gocode... https://mattn.kaoriya.net/software/lang/go/20181217000056.htm 僕は Vim を使っていて、幾らかの言語の開発環境は vim-lsp に移行できたのですが C/C++ を扱うケースだけ vim-lsp に移行できず vim-clang を使ってきました。C/C++ は clangd という Language Server を使
C言語の正しいヘッダファイルの書き方 - saito’s blog
最近、仕事でC言語での組み込み系の開発に携わっています。 開発中のコードを眺めていると、ヘッダファイル内にstatic関数のプロトタイプ宣言を記述していたり、ヘッダファイル内で不必要に他のヘッダファイルをインクルードしているなど、ヘッダファイルの書き方が分かっていないと思われる箇所が多々見られました。 実際、C言語の入門書でもヘッダファイルの書き方を詳しく説明しているものは、僕の知っている限りでは存在しないので、C言語を使っていてもヘッダファイルの正しい書き方を知らない人が少なくないのではないかと思われます。 そこで、このエントリでは、C言語のヘッダファイルの書き方について、僕が知っているテクニックをまとめてみました。 インクルードガードを書く ヘッダファイルファイルで他のヘッダファイルをインクルードしていると、いつの間にか同じヘッダファイルを2回インクルードしてしまうことがあります。 例
clangd導入メモ - Qiita
clangdとは clangのLanguage Server Protocol 実装。 LSPはMicrosoftが提唱しているIDE支援のための統一プロトコル。 Language "Server"とあるとおり、言語支援のためのサーバーが常駐する。この手の機構を個別に備えた言語として、TypeScriptのtsserverとか、C#のOmniSharpなどが挙げられるけど、それの汎用版。 clangdはLLVMのフロントであるclangをベースとしたサーバーで、LLVMプロジェクトが公式に開発している。 コンパイラなので、コンパイルエラーの検出はもちろん、コード補完やフォーマット、定義ジャンプと参照元ジャンプ等には対応している。 なので、clang-formatやRTagsといったclang系ツールも、LSPクライアントを導入してしまえば、これらの個別設定をしなくてよい。 clangdのイ
Makeでヘッダファイルの依存関係に対応する - wagavulin's blog
CやC++で書かれたプログラムをMakeを使ってビルドする、というのはUnix/Linuxではよく行われていることだが、ちゃんとしたMakefileを書くのは意外と難しい。 例えば以下の3つのファイルからなるプログラムを考える。 foo.h: 関数fooの宣言がある。 foo.c: 関数fooの実装がある。 main.c: 関数fooを呼び出す。 /* foo.h */ void foo(int a); /* foo.c */ #include "foo.h" #include <stdio.h> void foo(int a){ printf("%d\n", a); } /* main.c */ #include "foo.h" int main(int argc, char **argv){ foo(10); return 0; } Makefileは例えば以下のように書ける。 PRO
シンプルで応用の効くmakefileとその解説 - URIN HACK
makefileは一度作るとそれ以降編集する機会が少なくなるので意外と真面目に考える人は少なく、ネット上でもまとまった情報は多くない。 Linux系OS上（正確に言うとGNU MakeとGCC）で複数のC/C++ソースファイルから１つの実行ファイルを作成(make)するための汎用的なmakefileテンプレートを作った。名前はまだない。適宜ディレクトリ構成や設計などに従ってmakefileをカスタマイズする必要があると思うがそのベースにする。 このmakefileのいいところ コンパイル対象となるソースファイルをワイルドカードで指定できる。 ヘッダファイル、ライブラリ、オブジェクトファイルなどコンパイル、リンクに関連するどのファイルが外部で変更されていてもきちんと 差分 コンパイルされる。 makefile自体に説明書（この記事）がある。 makefile Gistはこちら。 COMPIL
GCC拡張の無効化 (と、それにまつわる細かい話) - 簡潔なQ
端的に言えば-pedantic-errorsを使えばよい。(できれば-std=...も併用したほうがいいだろう) 以下解説 GCCのC/C++コンパイラは、独自の拡張機能を導入している。これを無効化するオプションには2種類あり、意味が異なる。 C標準と矛盾する拡張機能を無効化する。 (C標準と矛盾しないかもしれない)拡張機能を無効化する/または警告を出す。 実は、C言語の規格は、それぞれのコンパイラの拡張機能を全面的に禁止しているわけではない。「正しいプログラム(strictly conforming program)を正しく動かす」ことさえ満たせばいいので、いくつかの拡張機能が有効化されたままでも、標準に準拠していると言える場合があるのだ。 C標準と矛盾する拡張機能を無効化する C標準と矛盾する拡張機能を無効化するには、 -std オプションでISO C/C++を指定すればいい。 C D
2016年、C言語はどう書くべきか (前編) | POSTD
(訳注：2016/3/2、いただいた翻訳フィードバックをもとに記事を修正いたしました。) (訳注：著者のMattより、「本文中で明言はしていないが、この記事の内容はx86-64 Unix/Linux/POSIXでアプリケーションをプログラミングする場合にフォーカスしている。他のプログラミング領域では、対象とするシステムに応じた(例： 8-bitの組み込みシステム、10年前のコンパイラ、多くの異なるCPUアーキテクチャで動く必要のあるアプリケーション、Win/Linuxでのビルド互換性など)特有のアドバイスが必要」との補足を頂いております。) 以下の文章は2015年の始めに書いたドラフトで、今まで公開していませんでした。私のドラフト用フォルダの中で誰の目も引かなかったため、大部分が書いた時のままです。公開するにあたり、単純に2015年を2016年に変更しました。 必要な修正、改善、苦情があり
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
mallocで確保したメモリをassert失敗時もお行儀よくfreeしたい
他人のコードや設計を見て1番これはあり得ないだろと思う実装はありますか？
Compilation database