/ 最近 .rdf 追記 設定 本棚

脳log[2019-11-07~]



2019年11月07日 (木) [C++] ムーブセマンティクスと右辺値参照。未だによくわからないけどちょっとヒントになりそうなことに気がついた(気がする)。題材は自分も答えが欲しかったこの疑問。「誰も疑問を呈していないことに自分は疑問なのですが、push_back と emplace_back にトレードオフの関係はないのですか? emplace_back に利点しかないのだとしたら、そもそも関数が分けられずにライブラリ側の push_back 自体の実装が効率の良いものに置き換わるだけで済んだように自分は想像しましたが……。関数が分かれている以上は何かしら使い分けしてほしい意図(ライブラリ側の意図)ががあるものではないのですか?」■よくわからない理由に、右辺値というものの見え方がプログラマとコンパイラの間で180度変わることがあるんじゃないかと思った。最初にそこを区別せずに、右辺値があーだムーブがこーだという文章を読んでも、それぞれが矛盾することを書いているように感じられるのではないか。■右辺値というのはこれまで一時オブジェクト、書き込みできない値、プログラマの制御下にない値だった。ムーブセマンティクスをプログラマが表現できることになり、右辺値でないものを右辺値であるとマークできるようになった。それはプログラマにとって、値に対する制御を手放すという意思表示である。ちょうどコピーした auto_ptr が所有権を手放すがごとく。■コンパイラから見ると従来の右辺値と右辺値であるとマークされた値は、自身が破壊のタイミングを握っている(渡された)、制御下にある値である。■最初の疑問に戻る。emplace_back(push_back のムーブ版だと思ってるけど実は知らない)を使用することは、プログラマに引数となった値に対する制御を手放すことを要求するので、プログラマ自身が意図を込めて選ぶべきものになっているのだと思う。■push_back にムーブ版のオーバーロードを追加することもできたと思うんだけど、できないんだろうか、できるけどやらない方がいいという判断なのだろうか。それはどういう? オーバーロードがあれば T v; c.push_back(move(v)) みたいなコードを書いて呼び分けることになったと思う。■たぶん std::move って書いても書かなくても同じな場面が多くあると思う。ムーブしてきた値を受け取る側からしても、&& と書いたからといって特別な何かが必ず期待できるわけではないらしいし。俺は煩わしいからできるだけ書きたくないし、書いた方がちょっとだけ嬉しい場面でも書かずに済ませたいクチ。■コンストラクタと代入演算子がムーブとコピーがオーバーロードされる例か。かつての auto_ptr の所有権移転コードのようなものを書くみたい。うっかりリソースを共有した状態にすると二重解放の罠。auto_ptr と違ってちょっとわかりにくいのは、値に対して所有権を持っていないというのがどういう状態か想像しにくいこと。ポインタであれば値が NULL であるとか、値はあっても弱参照でありいつまでデリファレンスできるか不明であるとかが想定されるのだけど。■おべんきょ。「C++のムーブと完全転送を知る - Fixstars Tech Blog /proc/cpuinfo」「メイドでもよく分る右辺値参照 - TXT.TXT」■git もだいぶ時間がかかったけど(ものぐさなだけとも言う)、だいぶ煮詰まってきたんじゃないだろうか。かつての C++ In-Depth シリーズのような本が読めないのが残念でならない。そういう研究が必要ないというのなら、C++ が言語として進化したのではなく単に充実しただけであるということ。進化がないのも研究書が読めないのもどちらも不満。■ムーブってついつい一時オブジェクトの省略(※コピーや移動の終着地点に最初から一度だけオブジェクトを構築して済ませてしまう)と結び付けて効率化の手段だと考えてしまうけど、プログラマが書いたムーブコンストラクタが実行されるなら、それはコピーコンストラクタが実行されるのと変わりがないのでは? 利点があるとすればメンバとして保持する外部リソース(ヒープメモリ、ハンドルなど)の確保が省略できる、奪い取って間に合わせられるという点にしかないのでは?■俺は auto_ptr が大好きだし、その制約も喜んで受け入れるし、Rust のメモリ管理も好きだけど(「Rustは何が新しいのか(基本的な言語機能の紹介) - いもす研 (imos laboratory)」)、ムーブは面倒くさいなあ。これまで通りコンパイラの最適化に期待するだけにして、面倒は避けたい、必要に迫られるまでは。


2019年11月06日 (水) [B! コミュニケーション] なぜ「事実」と「意見」を区別して話せない人がいるのか。 | Books&Apps」■タイトルから抱く期待と本文を読んだ感想が一致しない。そういう意味でブコメの流れはもっともである。■新聞の投書欄でたしか読んだけど、医者にかかって「風邪みたいなんです」「それを判断するのは私です(ムスッ」みたいなやりとりって感じ悪いじゃない(少なくとも投稿者はそう受け取っていた)。言い方があるだろうと(「どうしてそう考えたのか話してもらえますか?」)。最初に対立関係や上下関係を作って得する人間が存在するのかと(医者も患者も上司も部下も得していない。ただし医者と上司の目的がマウンティングである場合はこの限りにない)。で、誰が改める?■人間は道具ではないし、頭が付いてるし、それを活用できない上司が無能に見える。もちろんまだ信用して任せるには足りない新人かもしれなくて、判断のプロセスをいちいち確かめる必要があったのかもしれないけど、その場合でも上司に人を育てる視点がまるでないことが、やはり無能に見せる。勝手に育つ、骨のない奴はやめちまえ、なんてのは人余り世代の甘えでしょ。判断の機会を奪い、そのプロセスを鍛えることもせず、部下はいつまでも上司のためのテープレコーダーなのか?(テープ? IC と言い直しても同じだな。ボイスレコーダーが正解か)


2019年11月05日 (火) ミネルヴァの続刊をずっと待っていたのだけど、そのせいで他のシリーズに手を出せないでいたのだけど(そういう気質、あるよね)、作家には続刊か新シリーズかのオプションが与えられており、選んだ結果の新シリーズだったらしい。20190703のスライドの作者のツイッターからあいだに一人を挟んで再び名前を見かけることがなければそれまでだった。それは惜しい(どっちが?)。


2019年11月04日 (月) ひこにゃん(?)のアイコンでツイッターをやっている人をブックマークしていて、なんとなし歴史・地理・漢字クラスタに分類していたのだけど、ふいに AGC(AtCoder Grand Contest)に参加した話が出てきたりもして、たった一人の人間であっても底は知れない。


2019年10月31日 (木) 疑問に対する答え。「関心の分離や単一責任の原則に通じるところがあるんでしょうか?」■もっとミクロな話で、曖昧さを残さない、惑わせない、その余地を残さないってことだと理解している。■今回の件で言えば、ヌル終端されないケースがあるのかないのかということ。実際は固定長配列で間に合うのだから用意された配列にヌル文字が含まれないケースは存在しないと考えられる。だから仕様でヌル文字の存在を仮定する。存在しない場合を許さないし仮定しない。それが Assertive であるということ。■曖昧な態度をとれば論理がつながらないし、すべてのあり得るケースを十全にカバーしようとしたときに負担が増える。想定ケースに対して念のために1だけ余分に対応できるようにしたコードに対応するためにさらに1の余分が必要になり、それに対応するコードはさらに……。■カバーする必要性に気がつかずに、論理のギャップに対して2人の人間が異なる見方をすれば、それがバグの始まり。■追加された比較演算子のテストはヌル文字が存在しないケースにアイデンティティを与えて存在を認め、仕様として規定した。だとすれば今後(そして既存のコードも) MYDEVMODE の sz と名の付くメンバにヌル文字の存在を仮定することができなくなり、たとえばメッセージボックスをはじめとする文字列関数にそのまま渡すことがバグの温床になる。律儀にやるなら _MAX_PATH+1+1 のバッファに一時コピーしなければいけない。正気か?■現実をテストケースにすれば実装をいじる必要はなかった。実在しないケースをテストにして実装をそれに合わせたのがあの PR。正気か?■俺は怠け者だから行動する者には負けるけど(「うんこコード、放置しててすまんです」)、その動きが右へ進み左へ進みその間に後退もしている(前進はしていない)、というものではないかという疑いの目は向けている。■■■「一応、strncpy的な関数の使い方を誤るとNUL終端されない文字列を作れますので、絶対要らない対応、というわけでもないと思ってました。」 テストに対する勘違いがあると思う。ヌル終端しないコードに対してこのテストと実装の修正で何ができるのか、シナリオで示して欲しい。もちろんそれを伝えはしない。聞く耳ねーからな。無駄無駄無駄。■念のために書くけど、「ヌル文字の存在を仮定する」というのを「ヌル文字の存在を信じて暴走すべき(それを許容すべき)である」などと曲解されていては全く浮かばれない。ヌル文字の後ろを比較対象にするのがあるべき仕様の外であるなら(wmemcmp を使わない理由)、構造体のために確保されたメモリの外を比較対象にするのもあるべき仕様からは外れている(wcsncmp を使う理由)。どちらも否定していないし、今は無関係。混同している人間が誤っている。


2019年10月30日 (水) ぶん殴りたい。共通の理解の上で意見が合わないのなら、それは価値観の違いであり、それをどうこうすることはできない。だけどある程度共通のものがないとどうしたって戦争が避けられないから、批判に堪える出版物を引用する。自分個人の考えや感覚でそれができるとは考えない。しかし価値観以前に共通の理解をこの者との間に築くことができないせいで、無駄に消耗する。全くの無益。耳を塞いで他人にでたらめな要求を押し付けるふるまいを「犯罪的」だというのだ。自己の無謬性にそこまで確信を持てるとは大した自信家じゃないか。「本物は違う」とはこのことではないか。俺の方はといえば事実関係に白黒が付かないことに気も狂わんばかりになっているというのに。■https://github.com/sakura-editor/sakura/pull/1081#pullrequestreview-307582232 の指摘は最初から十分に理解できるものだった(なのに不備を詫びることができるのは報告者の人徳だ)。ここにアクセス違反のおそれがあるとヒントを与えられても見つけられない者に、最初から何が期待できるのかという考えもある。万事この程度の理解度で弁明する者のいない既存コードをふんわりざっくりけなすようなまねをするから、「お前が」「(わざわざ)言うな」の念が募る。■俺はこの者の人格に絶望している。


2019年10月29日 (火) 日曜日にあった ABC。ちょっと毛色が違った D 問題。「D - Water Bottle」■難しポイント。sin と tan 間違えた。弧度法から度数法への変換を間違えた。高校数学では tan/sin/cos しか習わないので Ruby の Math モジュールのドキュメントを漁って atan と atan2 と atanh のどれが自分の求めるものか確かめないといけなかった(しかも最初 sin 系の関数を試していて角度の変換も間違えた)。これが難しいとか高校生に鼻で笑われる。


2019年10月26日 (土) もうはばかる理由もないので最初(sourceforge.net)から思っていたことを書くけど、「定石だから」ってのは理由になりはしない。そもそもその「定石」がローカルルールや迷信の類ではないのかという疑いがあるが、そこをクリアしたとしてもやはり同じ。デザインパターンがそうだ。広く流布し認められたパターンであっても、パターンカタログに載っていること自体が、パターンを採用する理由になるわけではない。これまで読んだどのパターン本でも、パターンが適用できる具体的なシナリオと、パターンが持つメリットとデメリットの両方と、同時に比較考量すべき別のパターンが併記されていた。「定石だから」で留まるのは浅はかなんだ(「手段を目的化してしまうと見失いがち。手段は常に目的に対してテストされ、いつでも置き換えられなければいけない」)。盲信するならせめて対象として権威を選ぶくらいはしないと馬鹿なんだ。


2019年10月25日 (金) Android 9 Pie にインストールした VLC for Android 3.1.4。ファイルからの相対パスで音楽ファイルを列挙した m3u プレイリスト(文字コードは UTF-8)。パスに [] を含んでるファイルを再生してくれないので、それぞれ %5B%5D に置換する必要があった(※手を加えたのはファイルシステム上のパスではなく、プレイリスト内のパス)。なんで? 二重にパーセントエンコードされても不思議じゃないんだけど、なんで OK なの? これじゃ %5B という3文字を含むパスと [ という1文字を含むパスを区別できないじゃない。


2019年10月21日 (月) 旅行予約サイトの「今あなた以外に○○人が見ています」はウソだったことが判明 - GIGAZINE」■まじめに実装すると人とサーバーにコストがかかるし、下手すると逆効果(「今あなた以外にゼロ人が見ています」)の可能性があるので、完璧にコスト(手段)とパフォーマンス(効果)を最適化した結果だと思う。手段を目的化してしまうと見失いがち。手段は常に目的に対してテストされ、いつでも置き換えられなければいけない。


2019年10月17日 (木) 提出 #8002336 - AtCoder Beginner Contest 088」に対して1バイト縮めた「提出 #8002578 - AtCoder Beginner Contest 088」。でも Ruby で *最速* である hanada3355 という人の「提出 #5777010 - AtCoder Beginner Contest 088」を手直しするだけで 151 バイトのスクリプトになるんだよなあ(※p の引数解釈とか条件演算子と文字リテラルの解釈揺れをバージョン2.3.3に最適化すると多少縮むかも)。196 バイト、195 バイトのレベルではない。手法としては「ちょっとだけGOLFに走った」と同じなんだけど、見てしまってから真似はできない。発想の転換が欲しい。■とか書いている間に 187 バイトの「提出 #8002816 - AtCoder Beginner Contest 088」と 186 バイトの「提出 #8002824 - AtCoder Beginner Contest 088」。目の付け所がずれている。でも自分としては添削を受けているようでテクニックの引き出しが増えて良い。■■■矢継ぎ早にくり出される新アイディアが楽しい。特に出力変数 c に例外値 -1 の役割まで持たせてループのストッパーにするこれが白眉。「提出 #8007594 - AtCoder Beginner Contest 088」。■これもえげつない。「提出 #8007675 - AtCoder Beginner Contest 088」 Integer#to_i(2) のリテラル2を再利用するために t の初期値を1から2にしてしまう。つじつまを合わせるために問題由来のビット列 s の方を2倍してしまう。それでは釣り合わないんだけど W の代入文が省けるのと、2倍した s がループの停止条件としてそのまま使えるので総合して得する。■短いソースに何重にも意味を重ねてすべてがすべてと必然的に絡み合う感じ。最適化の極みよな。アルゴリズムと言語と個々の問題に対する深い理解がないとここまで自由にいじくれませんよ。


2019年10月15日 (火) 宇宙ツイッタラーXさんのツイート: "AtCoder Problems を更新しました。難易度推定アルゴリズムが改善され、いくつかの問題で難易度が低めに出ていたものが修正されました。 by @pepsin_amylase"」■AtCoder Problems が推薦する過去問がいい具合に苦しめてくるので時間が溶ける。ここ数日の睡眠不足はこれのせい。とても良い。


2019年10月14日 (月) ガソリンスタンドで見た注意書き。「給油中はエンジンを切りましょう」■思わず「え、そんなことができるの? 給油口を開けたあとですぐにキーを差し直してエンジンをかけるの?」と思ったのだけど、たぶん運転席周りのレバーでぱかっと開けられるのだろうなと気がついた。■プレス機なんかは両手で操作をしないと作動しないような仕組みになってるんじゃないかと思う。「両手操作式安全装置」というのがそうではないか。本の裁断に使っているカッターには「一人で作業するように」という注意書きがある。もともと片手で押し下げられるようなレバーではないので、そういう注意になっている。■給油口を鍵なしで開けられる車はなんと「便利」なんだろう。■最近のキーは鍵穴を必要としないみたい。そういう時代に合った車のインテリジェントさに期待してもいいのだろうか。実際どうなの?■アクセルを踏んだら自動でパーキングブレーキを解除しますよ、ってな「スマートさ」だけは知ってるんだけど。俺は信頼できない自分を縛るために信号停止のたび、渋滞中の一進一退のたびにサイドブレーキを引くんだけど、自動で解除されたら困るんだけど。