堕天使の煉獄
2022-09
11
04:05:39
軽い気持ちだったのに
なんとなーく、msvcの方もc++20対応完了したっぽいので、qtのほうのオプションをc++17からc++20に変更したらば。
QImage::fromData(result, u8"BMP");
susieプラグインから受け取った画像データをQImageに変換してる部分なんだけど、これがエラーになる。
むう?
なんでコレが? としらべてみると、
ttps://docs.microsoft.com/ja-jp/cpp/build/reference/zc-char8-t?view=msvc-170
こういうことらしい。
c++20だとu8""はconst char*とは明確に別物とされるようになったのね。
QImage::fromData(result, "BMP");
に変更すれば実行には問題ないのだけども。
unix環境とかだと問題ないんだろうけど(プレフィックスなしの""がデフォでutf8なので)winで、そんでもって、コンパイラはmsvcを使ってる場合だと厄介な感じになるんだよなこれ。
環境によって文字コードが何になるか決まってないって感じで気持ち悪い。
msvc使うケース、ゲーム開発なんかの場合では、独自のstringクラスで、内部コードはutf16で、Qtのコードと互換取るために文字列リテラルはu8""のみ使う感じの運用にしてたりするので。
というかほぼQStringのパクリのクラスを自前で用意してる感じw
なのでQtでもmsvcでもソースコード内の文字列リテラルは全部u8""固定にしてるのですが。
うん、なんか結局は気分的に嫌ぁな感じってだけなんですけどw
ここもu8""で統一したいのにぃっていう気分の問題……。
なんか結局、c++の、char型に1バイトの変数と文字列を扱うってのと2つの役割をもたせたがための混乱。コレ昔から言われてることで、だからc++は文字列関係ダメダメ何だよなって言われる原因の一つなのですが。
ここでもこの問題が尾を引いてる感じぽ。
うーん、まあこの手のconst char*で受け取る文字定数て、実際には今回の例だと
"BMP" == 0x42,0x4d,0x50
ていう数値を渡してるニュアンスなので、むしろ文字コードとか関わるべきじゃないのでu8"BMP"でなく"BMP"てするほうが真っ当な書き方……と考えるべきなのかなぁコレは。
うーんでもやっぱ、こういうケースの場合、そもそもconst char*でなくenum classとかに置き換えるべき部分じゃないのかなーとか。
asciiコードで定数とかやるからややこしいことになってるんじゃないかと。
そんな感じで、なんかもにょっとした気分のままコードを修正する今日このごろ。
んでもやっぱc++で文字列周りは鬼門だわ。
ついでに画像フォーマット関係の話
JPEGの後継画像フォーマットについて議論するスレ
ttps://mevius.5ch.net/test/read.cgi/cg/1148854872/
これはなんか思わず頷いた。
可逆に向いてるケースでそうしてるのか、非可逆で劣化ありでもとにかくサイズを小さく抑えたいからそうなってるとか、どういう意図で作られた画像なのかが拡張子だけでわかるほうがいいよなーと。
アニメ付きもいちいちアニメ付きかとか判定しなくて良くなるし。
同じ拡張子でいろんな用途に対応してるのって、ほんと面倒くさいんだよ……。
コードが分岐分岐でごちゃごちゃするので。
そんでもって、WebP最近広まってきたところで、まだ開発中らしいけどWebP2とかこれも混在するような未来とか面倒くさいなーとしかw
まあこの辺何が流行るか誰にも分かんないからなぁ。
なんにも手の打ちようがないんだけど。
んでもAVIF……なんか特許の問題クリアしてるから~とか言うの見ると、mp3に対するogg見たいな印象もあるなぁ。
限定された特定の用途では生き残るけど、広く一般には普及しなさそうな気も?
WebPは今年の2月に写真屋で待望の対応みたいな記事出てきたり。
結構遅い……のかな待望の、とか書かれてるぐらいだし。
sai2とかだともっと遅い……のかなw
調べてみたらFireAlpacaはまだ未対応ぽ。
なんとなく対応してんだろうなーとおもったクリスタも対応してない。
ペイントツール全般でまだまだほとんど対応してないって感じみたいねwebp。
そうなると、あんましまだ普及してるとも言えないような気も……。
まだまだこの辺、どうなるかわからない感じだなぁやっぱ。
QImage::fromData(result, u8"BMP");
susieプラグインから受け取った画像データをQImageに変換してる部分なんだけど、これがエラーになる。
むう?
なんでコレが? としらべてみると、
ttps://docs.microsoft.com/ja-jp/cpp/build/reference/zc-char8-t?view=msvc-170
const char* s = u8"Hello"; // Compiles in C++17, Error C2440 in C++20
const char8_t* s = u8"Hello"; // Compiles in C++20 or with /Zc:char8_t
こういうことらしい。
c++20だとu8""はconst char*とは明確に別物とされるようになったのね。
QImage::fromData(result, "BMP");
に変更すれば実行には問題ないのだけども。
unix環境とかだと問題ないんだろうけど(プレフィックスなしの""がデフォでutf8なので)winで、そんでもって、コンパイラはmsvcを使ってる場合だと厄介な感じになるんだよなこれ。
環境によって文字コードが何になるか決まってないって感じで気持ち悪い。
msvc使うケース、ゲーム開発なんかの場合では、独自のstringクラスで、内部コードはutf16で、Qtのコードと互換取るために文字列リテラルはu8""のみ使う感じの運用にしてたりするので。
というかほぼQStringのパクリのクラスを自前で用意してる感じw
なのでQtでもmsvcでもソースコード内の文字列リテラルは全部u8""固定にしてるのですが。
うん、なんか結局は気分的に嫌ぁな感じってだけなんですけどw
ここもu8""で統一したいのにぃっていう気分の問題……。
なんか結局、c++の、char型に1バイトの変数と文字列を扱うってのと2つの役割をもたせたがための混乱。コレ昔から言われてることで、だからc++は文字列関係ダメダメ何だよなって言われる原因の一つなのですが。
ここでもこの問題が尾を引いてる感じぽ。
うーん、まあこの手のconst char*で受け取る文字定数て、実際には今回の例だと
"BMP" == 0x42,0x4d,0x50
ていう数値を渡してるニュアンスなので、むしろ文字コードとか関わるべきじゃないのでu8"BMP"でなく"BMP"てするほうが真っ当な書き方……と考えるべきなのかなぁコレは。
うーんでもやっぱ、こういうケースの場合、そもそもconst char*でなくenum classとかに置き換えるべき部分じゃないのかなーとか。
asciiコードで定数とかやるからややこしいことになってるんじゃないかと。
そんな感じで、なんかもにょっとした気分のままコードを修正する今日このごろ。
んでもやっぱc++で文字列周りは鬼門だわ。
ついでに画像フォーマット関係の話
JPEGの後継画像フォーマットについて議論するスレ
ttps://mevius.5ch.net/test/read.cgi/cg/1148854872/
709名無しさん@お腹いっぱい。2022/08/14(日) 00:54:38.39ID:wRrdkn8y
>>702
個人的には
可逆圧縮.xxx
非可逆圧縮.yyy
とアニメーション画像.zzz の3パターン欲しい
これはなんか思わず頷いた。
可逆に向いてるケースでそうしてるのか、非可逆で劣化ありでもとにかくサイズを小さく抑えたいからそうなってるとか、どういう意図で作られた画像なのかが拡張子だけでわかるほうがいいよなーと。
アニメ付きもいちいちアニメ付きかとか判定しなくて良くなるし。
同じ拡張子でいろんな用途に対応してるのって、ほんと面倒くさいんだよ……。
コードが分岐分岐でごちゃごちゃするので。
そんでもって、WebP最近広まってきたところで、まだ開発中らしいけどWebP2とかこれも混在するような未来とか面倒くさいなーとしかw
まあこの辺何が流行るか誰にも分かんないからなぁ。
なんにも手の打ちようがないんだけど。
んでもAVIF……なんか特許の問題クリアしてるから~とか言うの見ると、mp3に対するogg見たいな印象もあるなぁ。
限定された特定の用途では生き残るけど、広く一般には普及しなさそうな気も?
WebPは今年の2月に写真屋で待望の対応みたいな記事出てきたり。
結構遅い……のかな待望の、とか書かれてるぐらいだし。
sai2とかだともっと遅い……のかなw
調べてみたらFireAlpacaはまだ未対応ぽ。
なんとなく対応してんだろうなーとおもったクリスタも対応してない。
ペイントツール全般でまだまだほとんど対応してないって感じみたいねwebp。
そうなると、あんましまだ普及してるとも言えないような気も……。
まだまだこの辺、どうなるかわからない感じだなぁやっぱ。
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:2080557 t:19 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