堕天使の煉獄
2016-03
25
22:53:07
考えられない
高橋克彦「竜の柩」、ようやく下巻に読み進んだのだけども。
何処の馬鹿だよコレ……公共の図書館の本だというのに、本文に赤のボールペンでワードに印がついてる……。
たまに哲学系とか学術系の本だと、コレはお前のノートか? って感じで要点を蛍光ペンでマーキングしてある本とかたまに見かけるんだけど、こっちは大学生かなんかが勉強してて、ついうっかりノートと勘違いしちゃったのかな? とかおもうんだけど(いや、それでも十分非常識だけどw)
普通の小説で、ペンでマーキングとかアホかと。
ほんと何考えてるんだろうねこういうこと平気でやる人。しかも赤のボールペンて……。
印ついてると、なんとなく注目しちゃうじゃないですか。でもそれって別に作者の意図とも関係ないし、もっと言えばそいつ以外の読み手にとっては、読み取る意図が違う場合もあるわけじゃないですか。
この言葉が重要ですよ。なんて他人に教えられながら読まされてる感じで、すこぶる気分が悪いっ。
極端な話、推理小説で、犯人だと疑わしい人物に印がついてるようなものですよ。それも読みながら印をつけてる感じだと、それが合っているのかも判らない。ミスディレクションをさそうような物で、まんまと仕掛けが嵌っていたとしても、印がついてたことで自然な嵌りかたとか不可能だろうし。
まあ、自分はそんな酷い目に遭ったことはないのですが、世の中には推理小説の犯人の名前が表紙めくった1p目にマジックで書いてある……なんていう本なんていう悪質なものもあるらしいですからね……。
まだマシな例だと、栞代わりの物すら無いのか? 本文に鉛筆でここまで読んだっていう印つけてるアホとか。鉛筆ならせめて消せよ。自分で買った本なら好きにすればいいけど、図書館の本んでそんな事するとか、ほんと何考えてるか判らない。
しかし、なんで上巻には無かったのに下巻だけにマーキングされてるのやら。
そして、個人的に下巻の方が一気に陳腐な内容になってて、ちょっと読むのが馬鹿らしくなってきてる所なのに……
んでもってぱらぱらと後ろの方のページをめくるとかなり後の方まで赤いボールペンの線が……。
読む気失せてきたなコレ……。
ついでに日記用にとってるメモネタ。
藤田和日郎 新連載
HUNTER×HUNTER 再開
田丸浩史 まだ
バスタード まだ
藤田和日郎の新連載始まったようで。月光条例はちょっと微妙な感じであんま印象に残ってないぽですが、今回はどうなんでしょうね。
ハンターも4月から再開とか。
田丸浩史の新作はまだなのかな。ラブやん終了後、すぐに次の連載の話題がでてたのですぐ来るのかと思ってたけど、来ないですね。
バスタードは……w
次~
Vulkan
ttps://ja.wikipedia.org/wiki/Vulkan_%28API%29
VulcanはQt5.7でサポート
OpenGLの次のやつらしいです。
最近ではOpenGLの仕様は最近のハードウェアには逆に足かせになってるらしく、最近のハード向けに刷新したものらしいですねVulkan。
Qt5.6がかなり遅れて最近リリースになったっぽいんですが……。なぜか日本語QT界隈まったくスルー。っていうか更新止まってるっぽい。QTの最新情報提供するオフィシャル的なサイト全然見なくなっちゃったなぁ。
ブラウザ戦争
ttps://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E6%88%A6%E4%BA%89
ここみると、QtWebEngineがかなり注目になってる感じでQT界隈熱そうなんですけども。
上記のVulkanサポート含め。
でもなんか雰囲気的に日本ではどんどん盛り下がってる感じっぽいのかね。
あとfirefox随分没落したなぁ……w
そいやつい先日、書庫ファイルの中身のファイル名を一定のルールでリネームしてくれるような物が欲しくて。
今までは一旦解凍して、リネームソフトでリネーム→再圧縮。とかやってたんだけど、これ自動で出来るの欲しいなってんで。
探してみると、正規表現で置換する……ってのはあったんですが……一番やりたいのは数字の桁そろえとかなんだよな。1,2,3,てのを001,002,003て感じに。
画像のビューワだと、1,10,11,12……2,20,21……と、一番頭の数字でソートしちゃう物が結構あるので。
で、そのくらいなら自分で作ってみるかな。とか思ったんですが、そこで結構おもうのが、ちょっとしたツールなんかでQTってちょっと取り回しが面倒な部分おおいんですよね。ランタイムのverかわるとリビルド必要だったり、ランタイム自体結構大きいので、汎用的に使えそうなツールなら公開とかしても良いかななんて思ったときに、ランタイムの容量が邪魔になる(数十MBある)。
その辺vc++とかvc#製はランタイムはOSに標準で大抵はいってるので、小さい容量で公開できるんですよね。
QT5.6がロングサポートなのもその辺の絡みなのかなぁ。
ライブラリのver変わる度にランタイムもverに合わせた物が必要になるので、QT製のツールと公開してる人って、QTのverをちょくちょくあげられなくて、古いverを使い続けてる運用になっちゃってるんじゃないかなとか。
(有料もしくはGNUライセンスの静的リンクでの実行ファイルなら問題ないんだけど)
んでもって、書庫周りって文字コードとか、バイナリとか考えると、C#よりはc++のが面倒なさそう。
そうなるとGUIはあきらめてコンソールアプリにするかな。
でもそうなるとオプションはコマンドラインしか使えないのも不便だなぁ。
でもいまさらvc++でGUIめんどいんですよね。いまさらMFCとかいうでっかい糞に顔突っ込む気にもなれないし……。
したら正規表現で置換できるやつ、ソースコード付だったりして。
コンソールアプリ版とそのフロントエンドのGUI版てのがあって。
で、コンソールアプリ版の方のソースコードの中の、正規表現で置換する部分をファイル名の末尾にある数字の桁を3桁にそろえるコードに書き換えてビルド。
コンソールアプリ版をGUI版のところにおいて実行。
これで、書庫ファイルの中身のファイル名桁揃え機能ゲットだぜっ!
とかやってましたw
しかし、やっぱc++って他人のコード読み解くのに苦労する言語だなぁ……。
書き方の自由度が高すぎる故に……。
あと書庫周りのライブラリって結構古いの多いのね。数も種類も多すぎて、それぞれ把握してどれを選択するのかとか、1から作ろうと思ったら大変だったなコレ。
とか、その辺をやってるソースコード眺めて思ったり。
zlibとかアーカイバ無しでzip作れるとかいうけど、普通のzipとは似て非なるzipファイルが作られるとか、7zipつかったzip生成のが最近はトレンドっぽいとか、相変わらずうにこーどとかの文字コード周りにまつわるトラブルはついて回る感じとか。
なかなか面倒な世界っぽい。
んでも微妙に気になったのは、この界隈の配布ファイルにlzhが使われてることが多いこと。これってもうレガシーな感じで、作者自身が使用の中止を訴えてたような。
でもアーカイバ関係だと、lzhは日本人製の国産アーカイバって事で界隈開発者的に敬意を払って使用……とかなのかな。
win98時代ぐらいまで国内ではzipと二分するぐらいのシェアがあったのも今は昔……。
あとプログラム関係だと……
filesystem周りで
namespace filesystem = std::tr2::sys;
std::vector<tstring> buf;
for (const auto& v : filesystem::directory_iterator(path)){
buf.emplace_back(v.path().string<TCHAR>());
}
たったこれだけでpathの位置のディレクトリ内のファイルとフォルダのパスのリストを取得できるのだけども。
このコード書いて、あれ? そういえばこれregexでもこういう書き方出来るんじゃね?
とおもったのだけど……。
これを
using RegexToken_Ite = std::regex_token_iterator<std::basic_string<TCHAR>::const_iterator>;
std::vector<tstring> buf;
for(RegexToken_Ite it(str.begin(), str.end(), token, -1), end; it != end; ++it) {
buf.emplace_back(it->str());
}
こんな風に
for(const auto& v : RegexToken_Ite(str, token, -1)) {
buf.emplace_back(v.str());
}
書けるんじゃね? すっきりー。
とか思ったら出来ないんでやんの。
regex_iteratorはRange-based forに放り込めないっぽい。
そういえば別件で調べてたときに、std::regex≒boost::regexは、c++11以前遙か前に作られたので、c++11の機能にまったく依存してないコードで書かれているとかで。
なのでregex_iteratorがRange-based forの要件満たしてないのも……。
ってかんじで結局泥臭く書くしかないのね……。
utf-32対応する頃には、この辺のstd::regexの中身も刷新されてるといいんだけどなぁ。
次~
先週だったかのタモリ倶楽部、楽器屋での試奏される曲ランキング。
うーん。やはりメタル畑の人間にはあまりにも乖離してる世界だなぁ。
狭いメタル界でずっと生きてきたので、何が一般的とか、メジャーとかよくわからんw
ギター試奏ランキング。
れっちりとかにるばーなとか、全然興味なかったからなぁ。まったくピンとこない。
クラプトンのレイラぐらいしか知ってる曲なかったな。
そしてベースの試奏、スラップばっかなのね。
昔、なんかスラップは楽器に傷つくから試奏でやると店員さんに怒られるとか聴いたことあるんだけど、最近はそうでもないのかな?(単にスラップ奏法の一般化が進んだってこと?)
そしてサックス……。
ルパンのテーマやコナンのテーマとかがランクイン。
サックスなぜかアニメ系が多いのにワラタ。
あとは、今日はなんか寒かったな。
季節の変わり目は体壊しやすいので気をつけないとな……。
何処の馬鹿だよコレ……公共の図書館の本だというのに、本文に赤のボールペンでワードに印がついてる……。
たまに哲学系とか学術系の本だと、コレはお前のノートか? って感じで要点を蛍光ペンでマーキングしてある本とかたまに見かけるんだけど、こっちは大学生かなんかが勉強してて、ついうっかりノートと勘違いしちゃったのかな? とかおもうんだけど(いや、それでも十分非常識だけどw)
普通の小説で、ペンでマーキングとかアホかと。
ほんと何考えてるんだろうねこういうこと平気でやる人。しかも赤のボールペンて……。
印ついてると、なんとなく注目しちゃうじゃないですか。でもそれって別に作者の意図とも関係ないし、もっと言えばそいつ以外の読み手にとっては、読み取る意図が違う場合もあるわけじゃないですか。
この言葉が重要ですよ。なんて他人に教えられながら読まされてる感じで、すこぶる気分が悪いっ。
極端な話、推理小説で、犯人だと疑わしい人物に印がついてるようなものですよ。それも読みながら印をつけてる感じだと、それが合っているのかも判らない。ミスディレクションをさそうような物で、まんまと仕掛けが嵌っていたとしても、印がついてたことで自然な嵌りかたとか不可能だろうし。
まあ、自分はそんな酷い目に遭ったことはないのですが、世の中には推理小説の犯人の名前が表紙めくった1p目にマジックで書いてある……なんていう本なんていう悪質なものもあるらしいですからね……。
まだマシな例だと、栞代わりの物すら無いのか? 本文に鉛筆でここまで読んだっていう印つけてるアホとか。鉛筆ならせめて消せよ。自分で買った本なら好きにすればいいけど、図書館の本んでそんな事するとか、ほんと何考えてるか判らない。
しかし、なんで上巻には無かったのに下巻だけにマーキングされてるのやら。
そして、個人的に下巻の方が一気に陳腐な内容になってて、ちょっと読むのが馬鹿らしくなってきてる所なのに……
んでもってぱらぱらと後ろの方のページをめくるとかなり後の方まで赤いボールペンの線が……。
読む気失せてきたなコレ……。
ついでに日記用にとってるメモネタ。
藤田和日郎 新連載
HUNTER×HUNTER 再開
田丸浩史 まだ
バスタード まだ
藤田和日郎の新連載始まったようで。月光条例はちょっと微妙な感じであんま印象に残ってないぽですが、今回はどうなんでしょうね。
ハンターも4月から再開とか。
田丸浩史の新作はまだなのかな。ラブやん終了後、すぐに次の連載の話題がでてたのですぐ来るのかと思ってたけど、来ないですね。
バスタードは……w
次~
Vulkan
ttps://ja.wikipedia.org/wiki/Vulkan_%28API%29
VulcanはQt5.7でサポート
OpenGLの次のやつらしいです。
最近ではOpenGLの仕様は最近のハードウェアには逆に足かせになってるらしく、最近のハード向けに刷新したものらしいですねVulkan。
Qt5.6がかなり遅れて最近リリースになったっぽいんですが……。なぜか日本語QT界隈まったくスルー。っていうか更新止まってるっぽい。QTの最新情報提供するオフィシャル的なサイト全然見なくなっちゃったなぁ。
ブラウザ戦争
ttps://ja.wikipedia.org/wiki/%E3%83%96%E3%83%A9%E3%82%A6%E3%82%B6%E6%88%A6%E4%BA%89
ここみると、QtWebEngineがかなり注目になってる感じでQT界隈熱そうなんですけども。
上記のVulkanサポート含め。
でもなんか雰囲気的に日本ではどんどん盛り下がってる感じっぽいのかね。
あとfirefox随分没落したなぁ……w
そいやつい先日、書庫ファイルの中身のファイル名を一定のルールでリネームしてくれるような物が欲しくて。
今までは一旦解凍して、リネームソフトでリネーム→再圧縮。とかやってたんだけど、これ自動で出来るの欲しいなってんで。
探してみると、正規表現で置換する……ってのはあったんですが……一番やりたいのは数字の桁そろえとかなんだよな。1,2,3,てのを001,002,003て感じに。
画像のビューワだと、1,10,11,12……2,20,21……と、一番頭の数字でソートしちゃう物が結構あるので。
で、そのくらいなら自分で作ってみるかな。とか思ったんですが、そこで結構おもうのが、ちょっとしたツールなんかでQTってちょっと取り回しが面倒な部分おおいんですよね。ランタイムのverかわるとリビルド必要だったり、ランタイム自体結構大きいので、汎用的に使えそうなツールなら公開とかしても良いかななんて思ったときに、ランタイムの容量が邪魔になる(数十MBある)。
その辺vc++とかvc#製はランタイムはOSに標準で大抵はいってるので、小さい容量で公開できるんですよね。
QT5.6がロングサポートなのもその辺の絡みなのかなぁ。
ライブラリのver変わる度にランタイムもverに合わせた物が必要になるので、QT製のツールと公開してる人って、QTのverをちょくちょくあげられなくて、古いverを使い続けてる運用になっちゃってるんじゃないかなとか。
(有料もしくはGNUライセンスの静的リンクでの実行ファイルなら問題ないんだけど)
んでもって、書庫周りって文字コードとか、バイナリとか考えると、C#よりはc++のが面倒なさそう。
そうなるとGUIはあきらめてコンソールアプリにするかな。
でもそうなるとオプションはコマンドラインしか使えないのも不便だなぁ。
でもいまさらvc++でGUIめんどいんですよね。いまさらMFCとかいうでっかい糞に顔突っ込む気にもなれないし……。
したら正規表現で置換できるやつ、ソースコード付だったりして。
コンソールアプリ版とそのフロントエンドのGUI版てのがあって。
で、コンソールアプリ版の方のソースコードの中の、正規表現で置換する部分をファイル名の末尾にある数字の桁を3桁にそろえるコードに書き換えてビルド。
コンソールアプリ版をGUI版のところにおいて実行。
これで、書庫ファイルの中身のファイル名桁揃え機能ゲットだぜっ!
とかやってましたw
しかし、やっぱc++って他人のコード読み解くのに苦労する言語だなぁ……。
書き方の自由度が高すぎる故に……。
あと書庫周りのライブラリって結構古いの多いのね。数も種類も多すぎて、それぞれ把握してどれを選択するのかとか、1から作ろうと思ったら大変だったなコレ。
とか、その辺をやってるソースコード眺めて思ったり。
zlibとかアーカイバ無しでzip作れるとかいうけど、普通のzipとは似て非なるzipファイルが作られるとか、7zipつかったzip生成のが最近はトレンドっぽいとか、相変わらずうにこーどとかの文字コード周りにまつわるトラブルはついて回る感じとか。
なかなか面倒な世界っぽい。
んでも微妙に気になったのは、この界隈の配布ファイルにlzhが使われてることが多いこと。これってもうレガシーな感じで、作者自身が使用の中止を訴えてたような。
でもアーカイバ関係だと、lzhは日本人製の国産アーカイバって事で界隈開発者的に敬意を払って使用……とかなのかな。
win98時代ぐらいまで国内ではzipと二分するぐらいのシェアがあったのも今は昔……。
あとプログラム関係だと……
filesystem周りで
namespace filesystem = std::tr2::sys;
std::vector<tstring> buf;
for (const auto& v : filesystem::directory_iterator(path)){
buf.emplace_back(v.path().string<TCHAR>());
}
たったこれだけでpathの位置のディレクトリ内のファイルとフォルダのパスのリストを取得できるのだけども。
このコード書いて、あれ? そういえばこれregexでもこういう書き方出来るんじゃね?
とおもったのだけど……。
これを
using RegexToken_Ite = std::regex_token_iterator<std::basic_string<TCHAR>::const_iterator>;
std::vector<tstring> buf;
for(RegexToken_Ite it(str.begin(), str.end(), token, -1), end; it != end; ++it) {
buf.emplace_back(it->str());
}
こんな風に
for(const auto& v : RegexToken_Ite(str, token, -1)) {
buf.emplace_back(v.str());
}
書けるんじゃね? すっきりー。
とか思ったら出来ないんでやんの。
regex_iteratorはRange-based forに放り込めないっぽい。
そういえば別件で調べてたときに、std::regex≒boost::regexは、c++11以前遙か前に作られたので、c++11の機能にまったく依存してないコードで書かれているとかで。
なのでregex_iteratorがRange-based forの要件満たしてないのも……。
ってかんじで結局泥臭く書くしかないのね……。
utf-32対応する頃には、この辺のstd::regexの中身も刷新されてるといいんだけどなぁ。
次~
先週だったかのタモリ倶楽部、楽器屋での試奏される曲ランキング。
うーん。やはりメタル畑の人間にはあまりにも乖離してる世界だなぁ。
狭いメタル界でずっと生きてきたので、何が一般的とか、メジャーとかよくわからんw
ギター試奏ランキング。
れっちりとかにるばーなとか、全然興味なかったからなぁ。まったくピンとこない。
クラプトンのレイラぐらいしか知ってる曲なかったな。
そしてベースの試奏、スラップばっかなのね。
昔、なんかスラップは楽器に傷つくから試奏でやると店員さんに怒られるとか聴いたことあるんだけど、最近はそうでもないのかな?(単にスラップ奏法の一般化が進んだってこと?)
そしてサックス……。
ルパンのテーマやコナンのテーマとかがランクイン。
サックスなぜかアニメ系が多いのにワラタ。
あとは、今日はなんか寒かったな。
季節の変わり目は体壊しやすいので気をつけないとな……。
Sun
Mon
Tue
Wed
Thu
Fri
Sat
01
02
■
■
小ネタ
03
04
■
■
聖なるウ○コ!
05
06
07
08
09
10
11
■
■
結局コレがいまだに一番……
12
13
14
■
■
時代を感じるw
15
16
17
■
■
んんん…
18
19
■
■
小ネタいろいろ
20
[春分の日]
21
■
■
小ネタいろいろ2
[振替]
[振替]
22
23
24
25
■
■
考えられない
26
27
28
29
■
■
良いタイミングで
30
31
■
■
んー微妙
total:2076526 t:38 y:396
■記事タイトル■
■年度別リスト■
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