堕天使の煉獄
2017-09
18
01:54:22
ある意味キモイ
なんか風つよいなーとおもったら台風きてたのですね。
窓を閉め切ってると空気がよどむ~。
そんな感じで相変わらずちまちまPG。
DXライブラリ@vc++
文字回りをガリゴリ。
gDebug() << u8"utf-8出力";
gDebug() << L"utf-16(wchar_t)出力";
QtのqDebugと同じ感じの記法でデバッグ出力出来る様に<<をオーバーロードすれば独自クラスの中身も出力できるのも同じ。
windows環境にあわせてワイド文字でもutf8でもどっちでもそのまま出力指定出来るところがちょっと違う所。
でもなんだかキモイなこれw
基本的にはdxf::stringという独自文字クラスを用意して、const char*はutf-8前提でutf-8も受け取れる様にして内部ではutf-16(std::wstring)で持つ(utf-8は受け取ったところでutf-16に変換する)感じに。
毎度utf-8で受け取るとそのたびに変換するコスト掛かっちゃうけど、まあ微々たるものだろう。ループの中なんかならL""つかえば変換掛からないし、使い方次第ぽ?
とりあえずこれで_T("")を使わなくて済むようになるのは大きい。
_T("")ていちいち打つのめんどいんですよね。そんでもってQtとかにコード持ってくときにも邪魔になるし。TCHARとかの将来性もよくわからんwin固有の邪魔くさい型もつかわなくて済む用になったし。
個人的な精神的衛生上の問題 > utf-8→utf-16の変換コスト
です(ぉ
で、次にQString風のフォーマット書式系も使える用にしてみたり。
dxf::string test5 = dxf::string::format(u8"フォーマット書式 %d %s", 15, u8"文字");
dxf::string test6 = dxf::string(u8"フォーマット書式 %1 そのに%2 aa%3bb").arg(u8"挿入").arg(L"あいうえお").arg(u8"三個目");
dxf::string test7 = dxf::string(u8" %1 %3 %2 %4 ").arg(100).arg(25, 4, 10, u8'-').arg(128, 4, 16).arg((char)128, 0, 2);
結果:
------------------------------------------------
フォーマット書式 15 文字
フォーマット書式 挿入 そのにあいうえお aa三個目bb
100 0x0080 --25 0b10000000
------------------------------------------------
作ってみたところで、argの数値→文字あたりの書式指定方法回りがちょっと厳しいなと。
arg(T value, uint digits = 0, int base = 10, dxf::DxfChar fill = dxf::DxfChar('0'));
宣言部分はおおむねQStringのパクリなんですが、base = 10のとこ、2にすると2進数、8にすると8進数16にすると16進数になるのですが。
そも普通に8進数なんか使わない。
2進数と16進数はほぼデバッグ用途ですよね。
んでもって2進数は中身はstd::bitsetを使ってるので桁数指定は引数じゃ指定出来ないstd::bitset<size_t N>とテンプレートパラメータで指定するので、定数じゃないと指定出来ないのですよ。通常は桁数を決め打ちするか
constexpr int kbit = sizeof(T) * CHAR_BIT;
ostr << std::bitset<kbit>(value);
って感じで2進数表記にしたい値の入ってる変数の型からサイズを指定するパターンが普通だとおもわれ。
そうなると、もともとbase = 2を指定したときにはuint digitsは不要になるんですよね。(そして2進数表記はもとから型サイズありきで自分で桁数指定する意味ももともと薄い)
しかし他の所の指定はデフォルト値も使用したいところではあるし、引数のオーバーロードでの対応はいろいろと無理があるなーと言う感じに。
template<typename T, std::enable_if_t<std::is_integral<T>::value, nullptr_t> = nullptr>
arg_hex(T value, uint digits = 0, bool prefix=true);
template<typename T, std::enable_if_t<std::is_integral<T>::value, nullptr_t> = nullptr>
arg_bit(T value, bool prefix=true);
なんて感じで2進数と16進数だけ別関数にした方が良いんじゃ無かろうかとか。
そうすることで、元のargのみの時の場合だとどうしたもんかなと思ってたプレフィックス(0xとか0b)の付ける付けないの指定も個別で対応できるし、そもそも2進数と16進数はほぼデバッグ用途と考えれば別関数に別けるのもまあ有りなのかなとか。
あとちょっと嵌ったのが、T valueにboolが来た場合
bool b = true;
dxf::string(u8"真偽 = %1").arg(b);
みたいなので、"true" "false"に置き換わるようなのも欲しいかなとおもって追加してみたらば。
dxf::string(u8"%1 %2").arg(u8"あああ").arg(u8"いいい");
の結果まで
"true true"
になってしまったり。
あーc++ではたしか文字リテラルってboolに暗黙変換されるとかいうルールあったなーと。
arg(const char* str)
があればこっちのが優先されるのだけども
arg(const std::string& str)とか
arg(std::string_view sv)だと
オーバーロードの優先順位的にboolのが先に候補に挙がってしまうっぽい。
そんな感じで、オーバーロードや引数、デフォルト引数、その辺の兼ね合いで結構いろいろと試行錯誤を繰り返し中。
sprintf系のフォーマット書式もなんだかんだでうっとうしいし、QString風のargでくっつけてく形も、argの方でいろいろアレンジ出来る幅はあるものの、結構面倒なことになってるなとQStringのドキュメントみておもたり。
argのオーバーロード結構使ったことないパターン結構いっぱいあるぽ。
ドキュメントみて初めて知ったけど、置き換え用指定の%nのnてQStringだと1~99まで使えるのね。
漠然と1~9個の9個までとかなのかなとかおもてました。
んでもまあ、自前で作ってる方のはゲーム用のなので、あんまし機能とか付けすぎてもなと。基本ゲームPGの場合は実行速度の方が重要度高いので。
%1%3%2 とかなってるときにちゃんと%1の次は%2を置き換えて~とかいう順番も端折って、番号なんか飾りですよとばかりに、とにかく%+数字がヒットした順番に置換ってのでもいいかなーとかも考えたぐらいで。
置き換え文字が1文字だとその文字自体が使えなくなってしまうので、番号とセットって感じの措置はやっぱ必要か……。しかしそれはそれで番号の意味無いってのもなんだか気持ち悪いなぁ。
ということで現状、結局数字順でちゃんと置換する形にしましたが……。%%とか二つつづき限定とかもいろいろ考えたりはしたのですけど。
試しに書いてみると……。
dxf::string(u8"フォーマット書式 %% そのに%% aa%%bb").arg(u8"挿入").arg(L"あいうえお").arg(u8"三個目");
コレはコレで、何処に何番目のargの値が入るのかわかりにくいし、argの個数が全部でいくつなのかもわかりにくいか………やはり番号は必要ぽ。
んでもQtのQStringで触ってた時には、いちいち番号ふるの面倒っちゃ面倒だなーという気はしてたりして。だいたい頭から順番てのがデフォで結局頭から連番以外で使う事は殆どなかったりで。番号の順番かえて置換位置変えるなんてのは、ごく稀にやった記憶があるぐらいで。
むーん。
しかし、ここ数年で随分と文字回りも書き方がいろいろと変わったなと実感。
std::sting_viewはかなり汎用性が高くてもはや無くてはならないってぐらいになってるし。
でも値→文字あたりでいろいろと書式指定で変換しようと思うと、相変わらずstringstreamとかつかわなならんのはなぁ。
#include <charconv> // c++17
std::to_chars
std::from_chars
なるものがあるようなのだけど、まだVisualStudio15.3.4の段階ではまだ追加されていないぽ。
でもこれも
C++1z ロケール依存なし、フォーマット解析なしの高速な文字列・数値変換
ttp://faithandbrave.hateblo.jp/entry/2016/08/24/181540
0埋めとか一部の機能が無いので、完全にコレ一本で……とはならないぽ。
でもこれ自体はかなりパフォーマンス重視らしいので、はやく追加されて欲しいなぁ。
そんな感じでゲームPGといいつつ、画面は真っ黒のまま。
デバッグ出力で文字みてるだけの最近……。
窓を閉め切ってると空気がよどむ~。
そんな感じで相変わらずちまちまPG。
DXライブラリ@vc++
文字回りをガリゴリ。
gDebug() << u8"utf-8出力";
gDebug() << L"utf-16(wchar_t)出力";
QtのqDebugと同じ感じの記法でデバッグ出力出来る様に<<をオーバーロードすれば独自クラスの中身も出力できるのも同じ。
windows環境にあわせてワイド文字でもutf8でもどっちでもそのまま出力指定出来るところがちょっと違う所。
でもなんだかキモイなこれw
基本的にはdxf::stringという独自文字クラスを用意して、const char*はutf-8前提でutf-8も受け取れる様にして内部ではutf-16(std::wstring)で持つ(utf-8は受け取ったところでutf-16に変換する)感じに。
毎度utf-8で受け取るとそのたびに変換するコスト掛かっちゃうけど、まあ微々たるものだろう。ループの中なんかならL""つかえば変換掛からないし、使い方次第ぽ?
とりあえずこれで_T("")を使わなくて済むようになるのは大きい。
_T("")ていちいち打つのめんどいんですよね。そんでもってQtとかにコード持ってくときにも邪魔になるし。TCHARとかの将来性もよくわからんwin固有の邪魔くさい型もつかわなくて済む用になったし。
個人的な精神的衛生上の問題 > utf-8→utf-16の変換コスト
です(ぉ
で、次にQString風のフォーマット書式系も使える用にしてみたり。
dxf::string test5 = dxf::string::format(u8"フォーマット書式 %d %s", 15, u8"文字");
dxf::string test6 = dxf::string(u8"フォーマット書式 %1 そのに%2 aa%3bb").arg(u8"挿入").arg(L"あいうえお").arg(u8"三個目");
dxf::string test7 = dxf::string(u8" %1 %3 %2 %4 ").arg(100).arg(25, 4, 10, u8'-').arg(128, 4, 16).arg((char)128, 0, 2);
結果:
------------------------------------------------
フォーマット書式 15 文字
フォーマット書式 挿入 そのにあいうえお aa三個目bb
100 0x0080 --25 0b10000000
------------------------------------------------
作ってみたところで、argの数値→文字あたりの書式指定方法回りがちょっと厳しいなと。
arg(T value, uint digits = 0, int base = 10, dxf::DxfChar fill = dxf::DxfChar('0'));
宣言部分はおおむねQStringのパクリなんですが、base = 10のとこ、2にすると2進数、8にすると8進数16にすると16進数になるのですが。
そも普通に8進数なんか使わない。
2進数と16進数はほぼデバッグ用途ですよね。
んでもって2進数は中身はstd::bitsetを使ってるので桁数指定は引数じゃ指定出来ないstd::bitset<size_t N>とテンプレートパラメータで指定するので、定数じゃないと指定出来ないのですよ。通常は桁数を決め打ちするか
constexpr int kbit = sizeof(T) * CHAR_BIT;
ostr << std::bitset<kbit>(value);
って感じで2進数表記にしたい値の入ってる変数の型からサイズを指定するパターンが普通だとおもわれ。
そうなると、もともとbase = 2を指定したときにはuint digitsは不要になるんですよね。(そして2進数表記はもとから型サイズありきで自分で桁数指定する意味ももともと薄い)
しかし他の所の指定はデフォルト値も使用したいところではあるし、引数のオーバーロードでの対応はいろいろと無理があるなーと言う感じに。
template<typename T, std::enable_if_t<std::is_integral<T>::value, nullptr_t> = nullptr>
arg_hex(T value, uint digits = 0, bool prefix=true);
template<typename T, std::enable_if_t<std::is_integral<T>::value, nullptr_t> = nullptr>
arg_bit(T value, bool prefix=true);
なんて感じで2進数と16進数だけ別関数にした方が良いんじゃ無かろうかとか。
そうすることで、元のargのみの時の場合だとどうしたもんかなと思ってたプレフィックス(0xとか0b)の付ける付けないの指定も個別で対応できるし、そもそも2進数と16進数はほぼデバッグ用途と考えれば別関数に別けるのもまあ有りなのかなとか。
あとちょっと嵌ったのが、T valueにboolが来た場合
bool b = true;
dxf::string(u8"真偽 = %1").arg(b);
みたいなので、"true" "false"に置き換わるようなのも欲しいかなとおもって追加してみたらば。
dxf::string(u8"%1 %2").arg(u8"あああ").arg(u8"いいい");
の結果まで
"true true"
になってしまったり。
あーc++ではたしか文字リテラルってboolに暗黙変換されるとかいうルールあったなーと。
arg(const char* str)
があればこっちのが優先されるのだけども
arg(const std::string& str)とか
arg(std::string_view sv)だと
オーバーロードの優先順位的にboolのが先に候補に挙がってしまうっぽい。
そんな感じで、オーバーロードや引数、デフォルト引数、その辺の兼ね合いで結構いろいろと試行錯誤を繰り返し中。
sprintf系のフォーマット書式もなんだかんだでうっとうしいし、QString風のargでくっつけてく形も、argの方でいろいろアレンジ出来る幅はあるものの、結構面倒なことになってるなとQStringのドキュメントみておもたり。
argのオーバーロード結構使ったことないパターン結構いっぱいあるぽ。
ドキュメントみて初めて知ったけど、置き換え用指定の%nのnてQStringだと1~99まで使えるのね。
漠然と1~9個の9個までとかなのかなとかおもてました。
んでもまあ、自前で作ってる方のはゲーム用のなので、あんまし機能とか付けすぎてもなと。基本ゲームPGの場合は実行速度の方が重要度高いので。
%1%3%2 とかなってるときにちゃんと%1の次は%2を置き換えて~とかいう順番も端折って、番号なんか飾りですよとばかりに、とにかく%+数字がヒットした順番に置換ってのでもいいかなーとかも考えたぐらいで。
置き換え文字が1文字だとその文字自体が使えなくなってしまうので、番号とセットって感じの措置はやっぱ必要か……。しかしそれはそれで番号の意味無いってのもなんだか気持ち悪いなぁ。
ということで現状、結局数字順でちゃんと置換する形にしましたが……。%%とか二つつづき限定とかもいろいろ考えたりはしたのですけど。
試しに書いてみると……。
dxf::string(u8"フォーマット書式 %% そのに%% aa%%bb").arg(u8"挿入").arg(L"あいうえお").arg(u8"三個目");
コレはコレで、何処に何番目のargの値が入るのかわかりにくいし、argの個数が全部でいくつなのかもわかりにくいか………やはり番号は必要ぽ。
んでもQtのQStringで触ってた時には、いちいち番号ふるの面倒っちゃ面倒だなーという気はしてたりして。だいたい頭から順番てのがデフォで結局頭から連番以外で使う事は殆どなかったりで。番号の順番かえて置換位置変えるなんてのは、ごく稀にやった記憶があるぐらいで。
むーん。
しかし、ここ数年で随分と文字回りも書き方がいろいろと変わったなと実感。
std::sting_viewはかなり汎用性が高くてもはや無くてはならないってぐらいになってるし。
でも値→文字あたりでいろいろと書式指定で変換しようと思うと、相変わらずstringstreamとかつかわなならんのはなぁ。
#include <charconv> // c++17
std::to_chars
std::from_chars
なるものがあるようなのだけど、まだVisualStudio15.3.4の段階ではまだ追加されていないぽ。
でもこれも
C++1z ロケール依存なし、フォーマット解析なしの高速な文字列・数値変換
ttp://faithandbrave.hateblo.jp/entry/2016/08/24/181540
0埋めとか一部の機能が無いので、完全にコレ一本で……とはならないぽ。
でもこれ自体はかなりパフォーマンス重視らしいので、はやく追加されて欲しいなぁ。
そんな感じでゲームPGといいつつ、画面は真っ黒のまま。
デバッグ出力で文字みてるだけの最近……。
コメント:2件
Re.まるるん
2017-09-22(Fri) 06:55:15
ちょっと主題とはずれるんだけど昔圧縮ファイルを解凍せずに中身みて不要なのをそのまま消せるの作ってなかったでしたっけ?
記憶違いだったらすまんのですが合ってたら使いたいなーと思うのだけど公開はしない予定?
記憶違いだったらすまんのですが合ってたら使いたいなーと思うのだけど公開はしない予定?
Re.織田霧さくら
2017-09-23(Sat) 00:26:52
あれはちょっと公開に向かないツールなので……
その理由のテキスト付でそっちの鯖のappのところに入れておいたのでみてくだはれ。
ほかにもついでに恥豚様とかも追加しといたです。
その理由のテキスト付でそっちの鯖のappのところに入れておいたのでみてくだはれ。
ほかにもついでに恥豚様とかも追加しといたです。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
03
04
05
■
■
でもまた暑くなったりするんだろうな
06
07
08
09
10
■
■
消されるわ
11
■
■
そんなもんだよな……
12
13
14
15
16
17
18
■
■
ある意味キモイ
[敬老の日]
[敬老の日]
19
20
21
22
23
[秋分の日]
24
25
26
27
■
■
もはや何処も信用が……
28
29
30
total:2080864 t:326 y:2908
■記事タイトル■
■年度別リスト■
2024年
2024年12月(0)2024年11月(0)
2024年10月(1)
2024年09月(2)
2024年08月(1)
2024年07月(1)
2024年06月(5)
2024年05月(2)
2024年04月(1)
2024年03月(6)
2024年02月(4)
2024年01月(3)
2023年
2023年12月(3)2023年11月(1)
2023年10月(2)
2023年09月(3)
2023年08月(3)
2023年07月(3)
2023年06月(7)
2023年05月(8)
2023年04月(2)
2023年03月(1)
2023年02月(2)
2023年01月(3)
2022年
2022年12月(4)2022年11月(3)
2022年10月(1)
2022年09月(3)
2022年08月(3)
2022年07月(2)
2022年06月(1)
2022年05月(3)
2022年04月(2)
2022年03月(2)
2022年02月(1)
2022年01月(6)
2021年
2021年12月(8)2021年11月(3)
2021年10月(4)
2021年09月(6)
2021年08月(2)
2021年07月(1)
2021年06月(3)
2021年05月(2)
2021年04月(2)
2021年03月(3)
2021年02月(1)
2021年01月(4)
2020年
2020年12月(3)2020年11月(7)
2020年10月(2)
2020年09月(3)
2020年08月(1)
2020年07月(3)
2020年06月(7)
2020年05月(5)
2020年04月(8)
2020年03月(4)
2020年02月(2)
2020年01月(4)
2019年
2019年12月(1)2019年11月(1)
2019年10月(2)
2019年09月(1)
2019年08月(3)
2019年07月(2)
2019年06月(2)
2019年05月(2)
2019年04月(4)
2019年03月(1)
2019年02月(7)
2019年01月(1)
2018年
2018年12月(1)2018年11月(1)
2018年10月(5)
2018年09月(1)
2018年08月(5)
2018年07月(1)
2018年06月(1)
2018年05月(1)
2018年04月(2)
2018年03月(2)
2018年02月(1)
2018年01月(1)
2017年
2017年12月(2)2017年11月(1)
2017年10月(2)
2017年09月(5)
2017年08月(8)
2017年07月(2)
2017年06月(1)
2017年05月(1)
2017年04月(3)
2017年03月(5)
2017年02月(7)
2017年01月(8)
2016年
2016年12月(7)2016年11月(2)
2016年10月(3)
2016年09月(7)
2016年08月(8)
2016年07月(10)
2016年06月(17)
2016年05月(6)
2016年04月(8)
2016年03月(10)
2016年02月(5)
2016年01月(10)
2015年
2015年12月(7)2015年11月(7)
2015年10月(13)
2015年09月(7)
2015年08月(7)
2015年07月(5)
2015年06月(4)
2015年05月(5)
2015年04月(2)
2015年03月(4)
2015年02月(1)
2015年01月(7)
2014年
2014年12月(12)2014年11月(8)
2014年10月(4)
2014年09月(6)
2014年08月(7)
2014年07月(4)
2014年06月(2)
2014年05月(5)
2014年04月(4)
2014年03月(8)
2014年02月(4)
2014年01月(8)
2013年
2013年12月(15)2013年11月(8)
2013年10月(3)
2013年09月(3)
2013年08月(8)
2013年07月(0)
2013年06月(0)
2013年05月(0)
2013年04月(0)
2013年03月(0)
2013年02月(0)
2013年01月(0)
■レス履歴■
■ファイル抽出■
■ワード検索■
堕天使の煉獄
https://rengoku.sakura.ne.jp
管理人
織田霧さくら(oda-x)
E-mail (■を@に)
oda-x■rengoku.sakura.ne.jp