=== へ統一することなどできはしない、というのが意見。=== を使うことでテキトーなものを投げ渡してもうまく対処してくれることが期待されてしまうし、実際それが仕様のうちになってしまう。それは俺の意図するものではない。(問い)「では 1 と "1" が等しくなるのが意図する仕様なのか」 (答え)「そんな(変数の型を意識しないような)コードは存在しない！！！」 個人の趣味でしか許されない？ TypeScript使えばえーんちゃう。TypeScriptが翻訳の結果として === を使うというのは(実際に使うかどうかは別にして)、意味が全然違って問題がない。それを意図や表現の改竄とは呼ばない。それらは今度は TypeScriptで書かれたソース上に存在するものだから。Ctrl+T(新しいタブを開く)、a(ブラウザに登録した検索キーワードであり、amazon.co.jpの頭文字でもある)、Delete(余計な補完を消す)、Enter(移動)で行くことがほとんどなんだけど、最近その先のページからウィッシュリストへのリンクが消えた。毎月購入するほとんどのものはウィッシュリスト経由でカートに入れている。消えたものを探してうろうろしたりはしない。■気がついたこと。それだけでアマゾン断ちはできる。アマゾンが離れていくのなら俺は追いかけない。アマゾンに依存してきていなければそれは可能。■あとね、マーケットプレイスで本の送料が統一価格ではなくなったけど、未だに「関東への配送料○○円」ってやってんだよね。そのうえ出品者のページから配送料テーブルが取り除かれ、すべて、カートに入れて精算直前の画面から出品者十把一絡げの合計送料いくら、で確認しろという。買えないよね。買い物に必要な情報を隠して、物を売る気がない。■ひょっとしたら配送料を決定するパラメータが増えて柔軟性が増した結果、注文確定直前まで実際の配送料がわからないことになったのだろうか。オープンプライスに感じる不便さみたいなものなのだろうか。例外的なプロモーションのために日常の使い勝手を犠牲にしたのだろうか。いいよ、さようなら。svk commit にあった。svk add a.txt b.txt && svk commit するとコミットメッセージを入力するためにエディタが起動し予めこう入力されている。「(改行)=== Targets to commit (you may delete items from it) ===(改行)A /path/a.txt(改行)A /path/b.txt」 試したことはないけど、Aから始まる行を削除することで一部の svk add のコミットを先送りできるのだと思う。もちろんコミット対象を指定して svk commit しても同じことができるんだけど、svk commit してから除外する作業フローが許されているし、実際にそうしたいだろうシチュエーションに誰でもが遭遇しうるだろうと思う。■GREP置換に話を戻すけど、改行が増減しない限りはうまくいくだろう。特定のファイルの特定の行が特定の内容を持っていることを確認してから、その行を対象に置換を実行する、というようなマクロなりコマンドなりがあると、既存の GREPなりタグジャンプなりを含んだ作業フローに組み込みやすいと思う。逆に言うと今の GREP置換は異質。スクリプトが使えない人が必要とするシチュエーションがあるのだろうとは想像できるけど、コマンドラインオプションで制御したくなる程度に、GREPと同じ程度に異質。いやひょっとして、GREPはそのあとでエディタで開きたいという考えがあって実行するけど、GREP置換の場合はどうだろう。■■■2003年に投稿されたマクロ>「Macro/投稿/133 Grep結果から複数のファイルをまとめて置換処理 - SakuraEditorWiki」 同じことを考え、とっくに作成している人がいた！最終更新: 2018-02-15T12:43+0900
メモ帳でできるように……と書くために今試してみたのだけど、挿入されたのが「00:49 2017-12-17」だった。なんだこのキモい並びは。年月日も時刻もフォーマットこそ OSの地域と言語のオプションに従ってはいるものの、その前後関係が決定的にYMD文化圏のそれではない。
メモ帳はどうでもいい。サクラエディタには「日付を挿入」コマンドと「時刻を挿入」コマンドがある。それぞれのフォーマットをカスタマイズできる。日付を挿入するコマンドを F5 に割り当てて、そのフォーマットを「yyyy-MM-dd HH:mm」にすればいいと考える。できない。日付書式と時刻書式が分かれていて同時に使用できないせい。
ソースを見れば一目瞭然だけど、Windowsが GetDateFormatと GetTimeFormatという２つの APIを公開していて、サクラエディタのコマンドがその薄い被せ物だというのが、おそらくこの不便な分離の理由。くっつけたっていいでしょ。
カスタムフォーマットの場合に限り GetDateFormatと GetTimeFormatの両方の APIを呼ぶ。そうでないと OSの設定で日付フォーマットを「'hh' yyyy'年'M'月'd'日'」みたいにしたときに hh がそのまま hh とは表示されなくなる。
書式文字列と書き込み先が同じポインタでも問題ないみたい。フォーマットに対して書き込み文字数の方が多い場合があるとしたら問題になるだろうか。ANSI版で日本語の曜日が書き込まれるときとか？
GetTimeFormatは時刻だけしか対応していなくて、日付を整形したい場合はGetDateFormatというAPIを使うことになります。これが2つに分かれている所為で、両方を一度に整形したい場合に実に厄介な問題が発生するんですが、まぁそれは置いておいて………。
置いておかないで。知りたい。
「tt」が「AM」になるのか「午前」になるのかは、実行したOSの設定次第です（日本語設定なら「午前」とか）。
それでは、日本語環境で「t」はどうやって表示されるのでしょう。
「AM」が「A」、「PM」が「P」に対応するみたいで、なんとなく「t」は「tt」の短縮形じゃないかと想像付くんですけど、果たして、「午前」「午後」はどのように短縮されるんでしょうかね…。
wwwwww
20170908p02で書いた明示的デストラクタ呼び出しと placement new の組み合わせがここでも。そんなにありふれてるかなあ。
20170908p02で結論が出てるけど、一時オブジェクトとスワップするのが最適解。ナンセンスに思えた途中の試行が実はいいセンいっていたという。さらに最近の C++ なら素直に移譲コンストラクタが使える(らしい)。
約200行ほどの関数です。別にどうと言うことの無い関数なんですが（個人的には幾つかに分割したいんですけど）、何故にinlineになっているのかっ！
インライン展開するには大きすぎるから。って言うか、そもそもインライン展開する必要ないでしょ。プログラムの起動時に1回だけ呼ばれる初期化用の関数なんだし。
自分がわりと inline を、とりあえず付けておこうっていう人間かな。このファイル(脳log[20170908p01] ツールチップ>a.patch)の中を inline で検索すると知れると思うけど。
基準は、今考えてるんだけど、以下のいずれか。
最近 C++ In Depthシリーズを読み返してるんだけど、そして実はシリーズに見えてシリーズとは書かれていないんだけど、『Efficient C++』の中に「シングルトン関数」という呼び名で３番目の関数のインライン考が載せられていた。同意するかは読み手に任されるとしても、そういう考えのもとにインライン化することもあるってことで。
２番目の「実質的に小さい」は、よく考えると嘘かもわからんね。呼び出す関数の引数が多かったり、呼び出すつもりの関数がインライン展開されたりすると、ソースコード上の見た目以上に大きいということがわりにありそう。
他の関数を真似してinlineをつけたんだと思うけど、「訳がわからんけど動くからそれで良いや」的にコンパイラを誤魔化すだけのテクニックなんて使用厳禁っ!
最近知ったんだけど、inlineを付けるだけで関数の多重定義によるリンクエラーが避けられるらしいですねえ>20170410。そういうことをしだすと、「道具として使う」を通り越して乱用の域に達してると思う。
pHを測る機械があって、ピッと簡単に数字が出るのかは実際に使わなかったから知らないけど、「原理も知らずに……(もにょもにょ)」というぼやきが聞こえてきたのが印象に残ってる。原理を知らないと手段の優劣も限界も条件にあった適切な選択もわからんもんね。
道具ってのは元をたどれば誰かが目的のために最適な手段を求めた結果として生み出された経緯があると思う。予め用意された道具を使っているだけではアマチュアの域を出られないのではなくて？ 知の高速道路に関係する話。開拓者とフォロワーの違い。大多数にはハイアマチュアも届かない存在かもしれんけど。
日付と時刻を同じひとつのフォーマットで指定できる。そのソースがたぶんここ>「HRESULT tePSFormatForDisplay(PROPERTYKEY *ppropKey, VARIANT *pv, DWORD pdfFlags, LPWSTR *ppszDisplay)」
[hHmst]が時刻を表すフォーマット文字としてリストでき、[dMyg]が日付の文字としてリストできる。時刻文字が見つかると日付文字が見つかるまで、日付文字が見つかると時刻文字が見つかるまで API 呼び出しを遅延し、切り替わる部分まで(もしくは文字列末尾まで)をフォーマット文字列として、対応する API を呼び出している。どんなフォーマットでも最低１回は GetDateFormat を呼び出してるっぽいのは、２値だと if 文の条件がシンプルに書けるからか。必ず１度は、それも最初に日付フォーマット文字に出くわすだろうという推定は、すごく妥当だと思います。
これが真摯な対応というべきものか。俺は２割のコーナーケースを捨てて過度にシンプルな解法を選びがち。
先に挙げたコードの通りの回答。たぶん AM とか PM とか Thu とか Sat とか Oct とかに展開された文字列が再度フォーマット文字として解釈されてしまうんだろう。まじめに挙げると問題のあるロカールでは問題ばかりだった。