altebute.hatenablog.com

犬も歩けば規格にあたる

boost 1.58 を Visual Studio 2013 環境で導入した

boost 1.58 を Visual Studio 2013 環境で導入した。
あまりにもサックリ出来てしまったので驚いた。

  1. boost 1.58 をダウンロードし、適切な位置に解凍
  2. 適切なコマンドラインでビルド
C:\boost_1_58_0>bootstrap.bat > build.log && b2.exe -j 12 >> build.log

以上。コマンドは上記の通り。
build.logにビルド時のログが出力される。

実際に使用する時はプロジェクト毎にパスの設定を行う。

対象 パス(例)
追加のインクルード ディレクトリ C:\boost_1_58_0
追加のライブラリ ディレクトリ C:\boost_1_58_0\stage\lib

パスはbuild.logにも出力されている筈だ。

うまくビルド出来ない場合は、開発者コマンド プロンプト for VS2013を使うとうまくいくかも知れない。スタートメニューにある筈だ。

参考文献

Nexus 6を購入して3ヶ月がたった

Nexus 6を購入して3ヶ月がたった。私的にはそれなりに満足しているが、良い所もあれば悪い所もあるので、つらつらと書き連ねていきたい。

良い所

  • 最新のOSが動く
  • 画面が大きい

悪い所

  • Lollipopは不安定
  • 大きすぎる
  • 重いので小指に負担がかかる
  • 価格が高い

Lollipop不安定問題

最新のOSが動く点はメリットであるが、その最新のOSが不安定なのが非常によろしくない。

購入当初はLTE通信が全く安定せず、3G通信で運用していた。その後、LTE通信に関してはネット上で散見される各種おまじない(各自ググられたし)を実践したところ解消した。

Lollipopの不安定さについては各所で指摘されている。私個人の利用においては、前述のLTE通信以外で困った事は無いが。

でかくて重い

画面が大きく見やすい事はメリットだが、流石に6インチは片手で扱うには大きすぎた。LMTを導入することでなんとか片手で使っているが、スムーズに扱えているとは言い難い。また、184gの重量はかなりの負担である。

片手操作を前提に、操作性、重量を保った上で、画面を大きくする事を考えると、そのバランスは5～5.5インチが落としどころであるように思う。一部ファブレットが採用している5.7インチは両手で扱うなら問題ないが、片手では厳しいだろう。

価格が高い

Nexus 5のコストパフォーマンスと比較すると、Nexus 6は如何にも高価である。勿論、キャリア販売の10万近くするスマートフォンと比較すれば(キャッシュバックなどを一切考慮に入れない場合)安いかも知れないが。

少し前までは、ハイエンドである事が一般的な用途でも快適さに直結していたが、最近はミドルレンジ以上なら十分に快適に扱えるので、ゲームをするユーザ以外のハイエンドに対する訴求力は失われつつあるように思う。かく言う自分もその一人である。

結び

コストパフォーマンス、重量、画面サイズ、カスタマイズ性等のバランスを総合すると、私的にはOnePlus Oneを買うべきだったのではないか、と今では思う。あるいはNexus 5から買い換える必要は無かったのかも知れない。

MacBookに対する所感まとめ

もう大分時間が経ってしまったが、新型MacBookが発表された。最近になって漸く店頭に並ぶようになり、私も触ってきたので、その所感を纏めたいと思う。

新型MacBookは正しく未来だ。小型のラップトップの多くはこうなっていくのだろう、と確信させてくれる製品になっている。しかしその「未来であること」がそのまま弱点になっている、とも感じた。

新しいMacBookのウィークポイント

既に多くのメディアでも述べられていることだが、1ポートで全てを担うUSB type-Cポートは如何にも貧弱であるし、マシンパワーはOS X Yosmiteを動かすには明らかにパワー不足だ。キーボードは良く出来て入るが、人によっては違和感を禁じ得ないだろう。トラックパッドは文句なしに素晴らしいが、その感圧センサを活かしたアプリケーションソフトウェアについては未だ未知数である。

私が思うに、現在の技術では、本来のMacBookの理想像を実現することは困難だったのだろう、と思う。それ故に、MacBookは「よく出来たコンセプトモデルをそのまま製品化した」ような製品になってしまったのではないだろうか。

MacBookの将来像とAirとの類似性

マシンパワーの貧弱さは、小型低消費電力のプロセッサの性能向上に伴って解決されて行くだろう。充電と拡張用のポートが共通の1ポートであるのは、システム全体の定格消費電力を、無線による充電が上回った時点で、その実装によって解決される。

多くのユーザ、特にこのMacBookのような、小型軽量なラップトップを必要とするユーザにとっては、1ポートのUSBのみ、という環境は必要十分な物となるだろう。より高い拡張性が必要なパワーユーザは、その需要にマッチした上位の製品を買えば良い。

ただし、「上位の製品」よりもこのMacBookは高価である。Core Mプロセッサをはじめとする、このような小型軽量なフォームファクタが、まだ普及していないからだろう。この点において、新しいMacBookは、2008年に初めて登場したMacBook Airに非常によく似ている。

当時のMacBook Airは20万円を超える高価な製品であるにもかかわらず、貧弱な性能と拡張性のため、多くのユーザには無視された。これを買ったのは極一部の生粋のMacユーザのみだったであろう。その後のMacBook Airが拡張性を上げ、価格を10万円前後にまで下げ、新規にMacを購入するユーザのための入門機となったのは周知の事実である。

恐らくAppleは、MacBook Airが行ったモバイルラップトップの再定義を、新しいMacBookによって再び行うつもりなのだろう。その未来のラップトップは、現在のMacBookにUSBポートを追加し、無線による充電に対応し、より高い性能とバッテリーライフを実現し、恐らくは2017年中期頃に登場するのではないだろうか。

Visual Studioで単一のプロジェクト内に同名のソース・ファイルが含まれていてもビルドが通るようにする方法

以下のコードはVisual Studio 2013のデフォルト設定ではエラーとなる。

// ./a/func.hpp 
void func_a();

// ./b/func.hpp
void func_b();

// ./a/func.cpp
#include <iostream>
#include "func_a.hpp"
void func_a()
{
  cout << "a" << endl;
}

// ./b/func.cpp
#include <iostream>
#include "func_b.hpp"
void func_b()
{
  cout << "b" << endl;
}

// ./main.cpp
#include "./a/func.hpp"
#include "./b/func.hpp"
int main()
{
  func_a();
  func_b();
  return 0;
}

原因は、./a/func.cppと./b/func.cppから生成される.objファイルが競合するためである。Visual Studio側の挙動については、以下の記事が詳しい。

Visual Studio 2008では同名のソースファイルを扱うことが出来ない件 - How to disappear completely
http://d.hatena.ne.jp/heisseswasser/20110602/1307014324
結論から先に書きますと、Visual Studio 2008では同名のソースがプロジェクトに含まれていると、どれかコンパイルされるかはファイルの更新日時に依存するようです。
...
一番古いファイルがビルドの対象となるようです。

また、上記の記事からリンクされている記事に、以下のような記述がある。

同名.cppファイルの自動解決は出来ないのか
https://social.msdn.microsoft.com/Forums/ja-JP/3c4e0904-d0ff-4f72-b619-6703f87e03f0/cpp?forum=vcexpressja
②ほかの設定法がある（たとえばプロジェクト→プロパティ→C/C++→出力ファイルに入れるべき適切なマクロが存在する）

以下のように設定することで、生成される.objファイルが競合せず、ビルドが通るようになる。

  1. ソリューションエクスプローラーからプロジェクトを選択
  2. プロジェクト(p)->プロパティ(p)->構成プロパティ->C/C++->出力ファイルを開く
  3. ASM リストの場所及びオブジェクト ファイル名を$(IntDir)から$(IntDir)%(RelativeDir)に変更する

上記のようにすることで、Visual Studioが各.cppファイルをコンパイルする過程で、先にコンパイルされたファイルが後でコンパイルされたファイルに上書きされる事が無くなる。各.cppファイルから生成される.objファイルは、元の.cppファイルの相対パスを保持したディレクトリに出力される。

デフォルト設定では、相対パスを無視して、ファイル名のみ保持するため、各.cppファイルをコンパイルする過程で、ファイル名が衝突すると先にコンパイルされたファイルが後でコンパイルされたファイルに上書きされてしまう。

Nexus 6 を逃したので次回入荷時に可能な限り確実に入手する

Android

とても怒っている。こんな、あっという間に完売になるなんて聞いてないぞ。

ただ怒っていても事は仕方ないので、本記事では次回入荷時に可能な限り確実に入手する方法について考える。

Nexus 6のGoogle Playストアでの販売から完売までは、日本時間で10日水曜日の26:00から30:00前後だったようだ。

米国のGoogle Playストアでは、毎週水曜日に在庫が補充されるらしいことが約束されているので、これは日本時間で販売が開始された時期と一致する。

よって、米国時間の水曜日、即ち日本時間の木曜日の0時あたりからPCにはりつき、ブラウザに自動更新を行う拡張機能を入れるなりなんなりして、にらめっこするしか無いだろう。

事前に仮眠を取っておいたほうがいいかも知れない。

VC++2013で非推奨属性を扱うdeprecated宣言を使う

C++14 には名前やエンティティに非推奨属性を付加するdeprecated attributeと呼ばれる規格が存在する。

[[deprecated]] attribute
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3760.html

が、残念ながら例によって例の如くMicrosoft Visual C++ 2013ではまだ使えない。

その代わり、VC++2013ではdeprecated pragmaと呼ばれるプリプロセッサディレクティブと、deprecated宣言が存在する。

deprecated (C/C++)
http://msdn.microsoft.com/library/c8xdzzhh.aspx
deprecated (C++)
http://msdn.microsoft.com/library/044swk7y.aspx

上記の機能を用いると、C4996ビルドエラーが生成される*1。

コンパイラの警告 (レベル 3) C4996 http://msdn.microsoft.com/library/ttcz0bys.aspx

ここで問題になるのは、VC++2013ではC4996は警告ではなくエラー扱いであることである*2。MSDNでは、あくまで「警告」としか書かれていない。罠だろうか。
このエラーを警告として扱うためにプリプロセッサディレクティブ#pragma warningを用いる必要がある。

__declspec(deprecated("This is deprecated function."))
void  DeprecatedFunction(){}

int main()
{
    __pragma(warning(push));
    __pragma(warning(3:4996));
    DeprecatedFunction();
    __pragma(warning(pop));
    return 0;
}

__pragmaは#pragmaを置き換えるマクロである。__pragma(warning(push))で全ての警告の設定をスタックに格納し、その後C4996の警告レベルを3にセットし、非推奨関数の呼び出し後に__pragma(warning(pop))を用いてスタックしておいた警告の設定をポップしている。
マクロの末尾にセミコロンを置いているのは、VSのスマートインデントでインデントがずれないようにするためである。

warning
http://msdn.microsoft.com/library/2c8f766e.aspx

警告レベルには1から4が存在し、大きいほど重要でない警告となる。あまり低くすると警告が表示されなくなってしまうので、今回は3にした。規定値では、Debugビルドでは警告レベル4は抑制され表示されない。

/w、/Wn、/WX、/Wall、/wln、/wdn、/wen、/won (警告レベル)
http://msdn.microsoft.com/library/thxezb7y.aspx

関数呼び出しそのものをマクロ化してしまえば、固定の警告レベルで警告を出すように出来るが、可能な限り自前でのプリプロセッサを用いたプログラミングは避けたいので上記の様なコードになっている。
MSがdeprecated attributeを実装してくれれば、この様な面倒な記述をしなくて済むのだが……

*1:「ビルドエラー」には「コンパイルエラー」も「警告」も含まれる。

*2:MSDNを見る限り、Compiler Error及びCompiler WarningはそれぞれBuild Errorの分類の1つらしい。警告なのかエラーなのかはっきりせず、物凄く紛らわしい。

Kindle Cloud Readerに自分のライブラリが反映されない場合の対処法

先日、国内向けにKindle Cloud Readerが発表された

Kindle Cloud ReaderにはChromeアプリがあり、AmazonからKindle Cloud Readerをインストールすることで、オフラインで読めるようになったりするのだが、これがうまくいかず、ライブラリに反映されない場合がある。

実は、Kindle Cloud Readerには read.amazon.co.jp 版と read.amazon.com 版の2種類のアプリが存在し、後者では日本のKindleストアで購入した本は反映されないのである。ライブラリに本が表示されない場合はドメインを確認しよう。