· 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に減らすと:
#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 を出し、どれだけ review を残し、どれだけ ticket を解決したかを集計し、数字で上司に成果を示そうとした。上司はただ、評価は成果だけで決まるわけではないと言った。数年後になって僕はようやく理解した——測定が目標になった瞬間、それはもはや良い測定ではなくなるのだと。イギリスの窓税からハノイのネズミ懸賞金、そして今日の PR 数による開発者評価まで、仕組みはまったく同じである。
- 画像のストレージと変換を Cloudflare Images に任せる Web ページに画像を一枚置くのはフロントエンドで一番簡単なことだ。でもそれをちゃんとやる——リサイズし、各フォーマットを生成し、トラフィックにも耐える——となると、実はひとつの解決策まるごとになる。だから僕は結局、原画一枚だけ渡して全部 Cloudflare Images に任せた。
- Access Keyはもう使うな Access KeyはAWSで見落とされがちなセキュリティリスクだ。OIDCとIAM Roleを組み合わせれば、GitHub Actionsはsecretなしで安全にAWSリソースを操作できる
- データベースの主キー: AUTO_INCREMENT、UUID、UUIDv7 バックエンド開発では主キーをどうするかをよく決める必要がある。auto increment か UUID か、衝突はどうするか、UUIDv7 と created_at + index の性能差はどれくらいか。実際に 2000 万件のデータで検証し、設計判断までまとめる。