RecentChanges Last 60

として起動し接続してください。4K画面としてリモートデスクトップが起動できます。

・見てくれがダサい！(・・・個人の感想です)

ちなみに C++03 くらいのコンパイラでも RTTI がサポートされていれば同じこと（型がキーの std::map）が出来るので目新しい小技ではありません。がしかしココまでシンプルには書けません。

サーバーにアクセスしエラーだったらメールで通知します。それを cron で定期的に実行します。

こちらのページを参考にし、手元で試した結果をシンプルにまとめました。ありがとうございます。

証明書の設定などは Webサーバーコンテナの環境変数に記述するのが基本なようで、それ以外の方法を見つけられなかったです。ご存じの方おられましたら是非ご教示頂きたいです。

• • WSL（Windows Subsystem for Linux）を使ってますのでそれも必要です。が、ダウンロードと解凍でのみ使ってるので、powershell や一般的な解凍ツールに挿げ替えることは可能だと思います。

さすがに、「このプロジェクトでは VisualStudio2017 を使うので 2019 はインストールするべからず！」みたいな開発環境ルールは避けたいので、VisualStudio2019 がインストールされている環境でも期待通り MSBuild.exe を叩ける bat を用意したので備忘録兼ねて載せておきます。

#recent(30)

      MYSQL_ROOT_HOST: "%"

• • MYSQL_ROOT_HOST は、デフォルトが"%"のハズだけど何故かそうならない版の為に追加。

VPN を繋げた状態のローカルPC で youtube とかを見たときに VPN を経由しないようにすることが重要で、もし VPN 経由しちゃってると AWS 側の通信量の激増に気が付かずにパケ死の可能性アリです。

裏技っぽい印象を受けてしまいますが C++14 では is_transparent を書くことでイケるようになります。

なお、こういう書き方は以前は出来なかったような気がするので、多分、最近の SQLite3 でサポートされるようになったんだと思います。

#prettify{{

が、AWS も日々進歩変更されてるので、すでに古い情報となってるかもしれません。そんな場合にはご指摘頂ければ幸いです。

スタックフルコルーチンはとても便利なんですが、コルーチン内で実行するには都合が悪いコードもあるかなと思います。
そんなとき、表コンテキスト（って言うのだろうか。通常スタックの状態のこと。）で処理をさせて結果を得るっていうことを、同期処理っぽく書くやり方を、忘れる自信があるので備忘録です。

というわけで、template クラスの中の template クラスの static 変数の実体や関数の中身を別に記述するとき、どうやって書くんだったっけ・・と悩んだ時のためにリファレンスコードとして残しておきます。

以上、だいぶ以前に書いたブログの記事を引っ張ってきました。

• 今時点の TypeScript2.0 はまだベータ版(RCなのかな?)ですが、そこは気にせず TypeScript 2.0.2 Beta for Visual Studio 2015 という plugin を使っています。

TypeScript 1.8 では標準で結合機能があるので、webpack 等を使わなくても結合は出来るのですが、プロジェクトの全ファイルを１つにしてしまうようで、あんまり使い勝手がよくありません。それに実は、ブラウザではそのファイルをそのままでは動かせなかったりと、自分としてはイマイチだなーと思ってました。

static メンバ変数を持ったクラスは、static 変数の実体を記述する為、cpp ファイル(ソースファイル)が必要になってしまいがちです。
おそらく、普通に書くとこんな感じ↑になると思います。

1. 1. 送信先 FreeNAS にボリュームを作成しておきます。

こんな感じで出たら、{155}ってのがアロケートしたカウントなので、まずこの値を覚えておきます。

#contents

• (↑こういうときに PHP のヒアドキュメントは色分けが正しくされなくて見にくくなってしまいますがご了承下さい)

php-pecl-redis php-pecl-xdebug php-opcache php-pecl-apcu とか

Bootstrap では collapse って名称ですが、collapse ってどんな意味だろうって調べたら、「潰れる」とか「崩壊する」とか出てきて、なるほどと思いました。
どちらも cookie を使って、リロードしても開閉状態を保持するようにしています。

C/C++では、同じ処理をさせるにもコードの書き方で吐き出されるマシン語コードに違いが出ます。
ここでは自分が有効かなと思っている最適化ネタを記載してます。
昨今のマシンスペックを持ってすれば、ちょこざいな小手先テクニックは不要と思っている方もいらっしゃると思いますし、確かに、わざわざ最適化する必要がない場合も多いと思います。
ですが、ソフトウェアという物は、要となる数箇所を最適化するだけで動作が快適になったり、逆に、なにも考慮されずに書いたコードが（塵も積もれば山となるで）ソフトウェア全体のパフォーマンスを悪化させる要因にもなりかねません。
昨今のコンパイラの最適化処理はかなり優秀ですし、今後さらに優秀になっていくと思われます。
しかし、その最適化処理を有効に機能させる為のコーディングテクニックが存在することも事実です。

最適化されたコードというのは、コードの見易さとトレードオフになるケースが多いですが、何も考慮せずに書くコードより、速度面やコストパフォーマンス、コードの読みやすさなど、全てを考慮しながらコーディング出来ることが、良いソフトウェアに繋がると考えておりますし理想だと思っています。

開発環境として、VisualStudio6 及び VisualStudio.NET2003 をターゲットにしており、WindowsAPIを使った例もありますが、基本的な考え方は多分どんな環境にも通じるであろうと思います。

もし掲載されている内容に間違いなどありましたら是非ご指摘ください。それ程自信がある訳ではないので、御意見、アドバイスなど頂けると大変嬉しいです。

written by takatsuka

その当時の見解で述べている記事ばかりです。古い情報となってしまっているものも多々あると思いますが、そこも踏まえ、ご意見やご指摘など頂けると大変ありがたく思います。

#lsx(技術系備忘録/C++/,notitle)

同じ NAT 内の端末同士は、ローカルIPで通信させるなり対策しなきゃ。（たぶん一般的なルーターでは、自分自身が開けたポートに自分自身から接続(ヘアピン)は出来なさそうなので）。とか。

BenchContainer.zip

BenchMap.zip

#lsx(会社案内,notitle)
#lsx(技術系備忘録,notitle)

通説ですが、"２のべき乗での乗除算は、シフト演算（ビットシフト）で処理したほうが早い"というのがあります。
CPUが高速化されたといっても、乗除算命令はそれなりに遅い処理で、比較するまでもなくシフト演算のほうが高速です。(List1)

• List1
  #prettify{{
  int Test(int n)
  {

  	return n << 3;		// ビットシフトを使う

  }
  }}

８倍する掛け算なのですが、２進数の仕組みを利用し、ビットシフトすることで８倍という処理を実現しています。
これは確かに有効な手段であり、古くからあるテクニックで、まったく問題ないと思います。

しかし、昨今のコンパイラは、わざわざシフト演算で記述をしなくても、シフト演算を使うコードを吐き出します。(VisualC++6で確認)
こうなると、シフト演算で記述しようと、掛け算で記述しようと、最適化の観点からはどっちでも良いということになります。

　・
　・
　・

というわけで、以上でこのネタは終わりでもよいのですが、ちょっとツッコンだ個人的見解を述べたいと思います。

自分は、昨今の最適化コンパイラを使う場合、素直に掛け算で記述するほうが良いと思っています。
理由は、コードの見易さと間違いの避け易さからです。

２のべき乗という単純な場合であれば、どちらの書き方であってもコードの見易さは変わらないと思いますが、それ以外の数で処理する場合、コードの見易さと間違いやすさは劇的に変わります。

１５倍する例を見てみます。(List2)

• List2
  #prettify{{
  int Test(int n)
  {

  	return ( n << 4 ) - n;

  }
  }}

これは、掛け算をビット演算に分解することで、掛け算命令を使わずに処理速度を稼ぐという、昔からある小手先テクニックです。１６倍から１倍を引くことで１５倍を実現しています。

この場合、最適化の面から言えば問題ないかもしれませんが、コードの見易さは大きく犠牲になってますし、１５倍をビット演算に分解する過程でミスを犯すかもしれません。

さらに、最適化の面からも、実は正解ではなさそうです。
List2 をコンパイルした結果（アセンブラ）が List3 です。

• List3
  #prettify{{
  int Test(int n)

  	mov  eax, DWORD PTR n
  	lea  eax, DWORD PTR [eax+eax*2]		// 3倍して
  	lea  eax, DWORD PTR [eax+eax*4]		// 5倍する

  }
  }}

期待した結果とは明らかに違いますが、これがコンパイラの最適化の結果です。

つまり、見辛い上に最適ではないコードを記述してしまったことになります。
（というか、どっちの記述でも出力されるアセンブラは List3 になります。ビット演算で記述してもコンパイラ(VisualC++6)は最適化してくれました。全然違う書き方でも同じように解釈するとは優秀です。）

以上の結果からわかるように、定数の乗除算程度は、素直にコンパイラ任せにするほうが、コードの見易さも犠牲にせず、しかも最適な結果になる訳です。

もちろん、コンパイラが優秀であればという条件が必要になるので、不安であれば念のため調べたほうが良いと思います。

/*
VisualC++の最適化性能がどんなもんか色々試しましたが、定数の乗除算についてはかなり詰められているようです。
とはいえ、CPU特性などを考慮すると、どういうアセンブラが最速なのかということは、一見しただけじゃ分かりません。
今回の例でも、コンパイラの出力が最速なのかどうかは確認も検証もしてません。しかし必要もないかなと思います。
*/

なお、一つ注意点があります。List4をご覧下さい。

• List4
  #prettify{{
  int Test(int n)
  {

  	return n / 8;

  }
  }}

一見何も問題なさそうです。コンパイラはシフト演算するアセンブラを出力してくれそうに思えます。
しかし、この場合は期待通りにはなりません。
それは型が int (符号付) だからです。単純にビットシフトすることは出来ないため、けっこう面倒なアセンブラが出力されます。

どうすればよいかというと、符号付として処理する場合はどうしようもありません。
しかし、"マイナス値の引数はあり得ない"という前提があるのであれば、List5 のように書くと、ビット演算のアセンブラを出力させることが出来ます。

• List5
  #prettify{{
  int Test(int n)
  {

  	return (unsigned int)n / 8;

  }
  }}

unsigned int にキャストすることで、符号無しで処理しなさいとコンパイラに教えています。
もちろん、このキャストによるオーバーヘッドというのはありません。変数 n を符号無しとして扱えとコンパイラに教えているだけです。

まとめとして。
昨今の最適化コンパイラのおかげで、定数の乗除算はどのように書いても最適化されたアセンブラが吐き出されるようですので、それを期待して素直な乗除算コードを書いたほうが良いと思います。
もちろん、最適化されないコンパイラや環境を使う場合、ビット演算でのコーディングは有効な手段だと思います。
List2 のような往年のテクニックも十分活かせると思いますので、知っておくことは損ではないと思います。

なお、言うまでもないかもですが、本ネタは整数演算を前提に書いています。浮動小数点演算についてはまったく当てはまりませんのでご注意下さい。