· 2分で読了
C言語における文字列処理
この記事は中国語から自動翻訳されたものです。翻訳によりニュアンスが失われている場合があります。
C言語では、strlen を使って文字列の長さを取得できる。しかし、strlen の呼び出しは毎回 であるため、文字列操作を頻繁に行うアプリケーションにおいて、文字列の長さが大きい場合はパフォーマンスのボトルネックになりやすい。特にトラフィックが多いアプリケーションでは顕著だ。一つの解決策は、別の変数で文字列の長さを保持しておき、文字列に対する操作が発生するたびにその変数を更新することだ。こうすれば、文字列の長さを参照する際はその変数にアクセスするだけで済み、時間計算量は になる。
もう一つ注意すべきなのは、C言語はバッファ長について何ら前提を設けてくれないため、連結(concat)などの操作を行う際には細心の注意が必要となる点だ。例えば、strcat を使って書く場合:
#include <stdio.h>
#include <string.h>
int main(void) {
char buf1[20] = "abc";
char buf2[] = "def";
strcat(buf1, buf2);
printf("%s\n", buf1);
return 0;
}
このコードは buf2 の内容を buf1 に結合し、buf1 の末尾に連結する。しかし、もし buf1 のサイズを 5(コード上は 4)に減らすと:
#include <stdio.h>
#include <string.h>
int main(void) {
+ char buf1[4] = "abc";
char buf2[] = "def";
strcat(buf1, buf2);
printf("%s\n", buf1);
return 0;
}
実行するとプログラムにエラーが発生することがわかる。これは buf1 と buf2 が結合された後のサイズが 4 を超え、バッファオーバーフローを引き起こすためだ。解決策は、concat 操作を実行する前に、結合後の文字列の長さがオーバーフローを引き起こさないかあらかじめ確認し、もし溢れる場合はメモリサイズを再割り当て(再確保)することだ。
関連記事
- 測定が目標になるとき:窓税からPull Request数まで かつて僕は小さなツールを自作し、四半期で自分がどれだけPRに貢献したか、レビューコメントをどれだけ残したか、チケットをどれだけ消化したかを集計して、上司にアウトプットを証明しようとしたことがある。上司は淡々と、評価はアウトプットだけで見るものではないと言った。数年後、僕はようやく理解した――測定が目標になるとき、それはもはや良い測定ではなくなるのだ。英国の窓税、ハノイのネズミ駆除の報奨金から、現代のPR数による開発者評価に至るまで、そのメカニズムはまったく同じだ。
- Cloudflare Images を画像ストレージ・変換ソリューションとして使う ウェブページに画像を1枚置くのはフロントエンドにとって最も簡単なことだが、リサイズや各種フォーマットの生成、さらにはトラフィックの負荷に耐えることまで完璧にやろうとすると、実際には一つの包括的なソリューションが必要になる。僕はその後、すべて Cloudflare Images に任せるようになり、オリジナル画像1枚だけを渡すようにしている。
- もう AWS Access Key を使うのはやめよう Access Key は AWS において見落とされがちなセキュリティリスクだ。OIDC と IAM Role を組み合わせることで、GitHub Actions にシークレットを一切保持させることなく、安全に AWS リソースを操作できるようにする。
- データベース主キー:AUTO_INCREMENT、UUID、そしてUUIDv7 バックエンド開発で度々直面する主キーの決定。auto incrementを使うべきか、それともUUIDか?衝突への懸念は?UUIDv7とcreated_at + インデックスの性能差はどれほどか?実際に2,000万件のデータで検証したベンチマークと設計上の意思決定を解説する。