- 締切済み
あったらいいなと思う、C文字列ライブラリ関数
みなさんC言語で開発してきた中で、ライブラリとして用意されてたら いいなと思った事のある関数・処理としてどのようなものがありますでしょうか。 特定業務向けの話でなく、汎用的な処理ででも結構です。 例えば、いつも思うのが、なんで文字列A中の文字列Bを、文字列Cに置換する 関数ってなんでないんだろう、などですかね。 (そりゃstrstr、strcatなど既存ライブラリ関数を使いまわせば書けますが...)
- みんなの回答 (7)
- 専門家の回答
みんなの回答
- kmee
- ベストアンサー率55% (1857/3366)
そういう具体的な話なら、事情が違ってくるわけで。 もっとも、私なら、(既に出ていますが)ラップ関数作りますが。 「変換のオーバーヘッド+既存の関数」と「自作関数」のどちらが効率がいいかなんてわかりませんし。 システムで使うコードとOS基本の内部コードが違う、などとは、よくある事です。 プラットフォームが変更されたが、データやアルゴリズムは過去のものをそのまま使いたい、とか。
- chie65536(@chie65535)
- ベストアンサー率44% (8756/19869)
>私の今関わってる案件が、OSの提供する文字列ライブラリ関数が、sizeof(wchar_t)==4の環境で、 >その上で動くアプリの吐く文字列が1文字2バイト固定っていう、ちょっと困った環境でした。 自分だったら、入力と出力にラップして、入って来る物はすべてsizeof(wchar_t)==4に変換しちゃって、内部表現は常にsizeof(wchar_t)==4にしといて、OS提供ライブラリ使って、出力の際に要求仕様に合わせてsizeof(wchar_t)==4形式を別形式に変換して出力しちゃう。 そうすりゃ、余計なライブラリは、1つも作らなくて良い。入出力をラップしちゃうだけで、全部、事足りる。 「変な環境に合わせて、ライブラリ全部作っちゃった」としたら、上司から「何アホな事やってんだ」って怒られるレベル。システムの設計間違ってる。
- chie65536(@chie65535)
- ベストアンサー率44% (8756/19869)
カンマで区切った文字列と、文字列や整数や実数などが代入できる汎用配列変数を渡したら、カンマでデータを区切って数値や実数や文字列を配列に格納して、各要素のデータタイプも格納してくれる関数が欲しい。 "0.123,abc,0x12e,1.3e+3"って文字列とarg配列を渡したら、arg[0].d_valueに0.123、arg[1].c_strに"abc"、arg[2].l_valueに0x12e、arg[3].d_valueに1.3e+3が入って、各要素のarg[?].typeにデータタイプが格納されて、戻り値として格納データ個数の「4」が返って来るとか。 scanfに似てるけど、scanfは「どういうデータが来るか順番に書かないといけない」から「どんなデータが来ても良い」ってのは出来ないんだよね。
補足
strtokに似た事かな...と思いましたが、任意の型を扱うってのと、 戻り値に格納した結果の個数をってのが違いますね。 strトkをラップしようにも、任意の型ってのが難しそう。 とりあえず文字列で返すから使う側で意識するって形であれば、 何とかなるかもしれませんが。
- jacta
- ベストアンサー率26% (845/3158)
char16_t型とchar32_t型用の関数一式と、それらの型にchar型やwchar_t型を含めた文字、文字列の相互変換や比較関数があればよいのにと思いますね。
補足
char型、wchar_t(4バイト)、2バイト固定長文字列の間の相互変換関数や、str*やwcs*に対応する 2バイト固定長文字列関数一式を、sizeof(wchar_t)=4の環境で作りました。 私の今関わってる案件が、OSの提供する文字列ライブラリ関数が、sizeof(wchar_t)==4の環境で、 その上で動くアプリの吐く文字列が1文字2バイト固定っていう、ちょっと困った環境でした。 で、一式作った後で、他にもよくありそうなものは追加してもいいかなという状況になってて、 だったらどんなものが良いだろうと思い質問してる次第です。
- kmee
- ベストアンサー率55% (1857/3366)
こんなの欲しい、って思うと、大抵有名なライブラリがあったりするし。 例えば、 > 文字列A中の文字列Bを、文字列Cに置換する なんて言うのだと、regex.hとかPCREとかがあるし。
補足
この環境では、char型文字列のについては標準Linux環境で使えるものはほぼ何でも使えますが、 Unicode文字列については、OSに載ってるライブラリが4バイトのwchar_tで、アプリケーション上で 使用する文字列が2バイト固定長なので全く使えないという状況です。 それはさておき、日本語など非英数データを扱う処理って、Unix/Linuxでみんなサクサク作れてるん ですかね。仮に扱う文字列がwchar_t型に合ってたとしても、そもそもwchar_t扱える文字列関数が そもそも多くないのではという気が。
- tsunji
- ベストアンサー率20% (196/958)
パソコンとかメモリ容量とか速度を気にしないなら便利なんでよく使うけど、 組み込み用途だと、標準関数を使うと遅くなったりメモリを食うので、欲しいのは 自分で作りますね。
補足
具体的に言うと、某データベース製品の機能拡張(ユーザー定義モジュールをフックできる個所)で使う文字列関数ライブラリです。 プラットフォーム的には、メモリ数百GB、CPUも数十コア、かなりふんだんにあります。
- zwi
- ベストアンサー率56% (730/1282)
そもそも自分で拡張するのがC言語だから特にいらないかな。標準ライブラリが肥大する方が嫌。
補足
全くない環境からstr*とwcs*に相当するものを作ってから、それだけだと足りないのは何だろうという話になってるのです。 今作業してるシステムで扱うデータがUCS2、OSにインストールされた文字列関数ライブラリはchar型と4バイトwchar_t型(UCS4)なので、標準のstr*とロケール関係を除くwcs*に相当する2バイト固定文字列の関数を一式作り終えた段階です。 自分でも似たような事を何回もコード書いてる事があるので、だったらライブラリ化に追加したいなと。
補足
そっち(2バイト固定長文字列ライブラリの作成)に突っこみが来ましたか。 「アホな設計」はどっちかっていうと2バイトwchar_tから4バイトwchar_t環境へ移行した 当時の上層部の決断だと思ったんですがね。 やってる内容が、最近よく言われるビッグデータ的な内容で、膨大なデータ、それこそ 一項目あたり数十KBって文字列(商品説明、顧客回答、etc.)てのがたくさんあり、 入出力のラップのオーバーヘッドもできれば削減したいって考えなんです。 それこそ数十TBってデータを扱うので。 で、製品本体が使う部分じゃないので、上司もとやかくいう筋合いはないし。 ライブラリ全部作ったって言っても、せいぜい型の部分を変えて全コンパイルすれば済むレベル。 テストそのものも仕組を整えてテスト項目追加⇒実行が数分でできるようになったし。