DirectXの入門本を進めている際、Visual Studio 2019において、いま作っているプロジェクトをコピーして、それに別名をつけた上でソリューションに追加したくなったのでそのメモ。
ようはこういう事↓。
Pythonのfor文は、C++でいうところのRange-based for文、C#で言うところのforeachと同等の動作をする。つまり、
for (int i = 0; i < 10; i++) {}
のようなforが存在しない。
Pythonのfor文において、iterable objectをenumerate メソッドに渡すと、添字付きRange-based forができる。
l = [100, 200, 300] for i, num in enumerate(l): print(i, num) # 0 100 # 1 200 # 2 300
これが非常に便利なのでC++でも同じ事ができないかなーと調べてみると、あった。
（リンク先に載っている実際のソースコードはここには載せない）
というわけでC++のRange-based for文でもPythonの enumerate 同等の、インデックス付き走査が可能ということが分かった……
と、ここで終わってはクソ記事もいいとこなので、この実装を参考に逆順に走査するイテレータを自作することにした。
まず、リンク先の実装で問題なところを挙げてみる。
operator++ の返り値がvoidになっているstd::begin や std::end の形でイテレータを取得しているので、ユーザが独自に定義したiterable objectに対応できない（わざわざ std::begin 、 std::end をオーバーラップしなければならない）今回の実装では 面倒なので 3. の問題については無視することにした。
また逆順に走査するためには、対象のiterable objectは rbegin と rend 、つまり逆イテレータを持っていなければならない。従って SFINAE を使って rbegin rend を持たないオブジェクトを渡した時はコンパイルを通さないような実装とした。
(2020/04/12/18:30 コメントでの指摘通りに修正）
template <typename Range, typename reversed_iterator = decltype(std::declval<Range>().rbegin()), typename = decltype(std::declval<Range>().rend())> constexpr auto Reversed(Range&& range) { struct iterator { reversed_iterator iter; bool operator!= (const iterator& end) const { return iter != end.iter; } auto& /* void */ operator++() { ++iter; return iter; } auto& operator*() const { return *iter; } }; struct iterator_wrapper { Range iterable; auto begin() { return iterator{ iterable.rbegin() }; } auto end() { return iterator{ iterable.rend() }; } }; return iterator_wrapper{ std::forward<Range>(range) }; }
operator++の行に謎のコメントが残っている。
auto& /* void */ operator++() { ++iter; return iter; }
実は今の実装のままだと、MSVCではコンパイルが通らない。
調べてみると、どうやら現在のgccのvectorの実装では vector::begin() をデクリメントしても、エラー終了しないらしい（当然Undefined Behaviorなので本来はやるべきでない）。一方MSVCの場合、 vector::begin() をデクリメントした時点で、 can't decrement vector iterator before begin というエラーメッセージと共にエラー終了する。
そのため、この関数をMSVCで使いたいときは、悪い実装ではあるがoperator++の実装を以下の通りに変える必要がある。
/* auto& */ void operator++() { ++iter; /* return iter; */ }
Cppmap で紹介されていたC++用単体テストフレームワークであるCatchをVisual Studio 2019で使ってみたので、その導入に関するメモ。
説明のために、Visual Studio 2019 (以下VS2019) で、空のプロジェクトを作成。整数を受け取り2倍の値を返す関数 int mul2(int) を作る。
次に単体テストを実行するためのプロジェクトを追加で作成する。今回は、テスト用のプロジェクトの名前を TestProjectとした。
TestProject以下に空のヘッダファイル catch.hpp を作成する。
続いて、Catchの公式リポジトリ から、 single_include/catch2/catch.hpp を見つけ、その中身を全コピーする。catch.hppは include ディレクトリ以下にも存在するが、こちらではない。私はこれに気づかず時間を潰してしまった。
次にTestProject以下に Test.cpp を作成し、以下を記述する。
#define CATCH_CONFIG_MAIN #include "catch.hpp"
これでCatchの導入完了。
TestProject以下に、最初に作成した mul2() 関数をテストするための testMul2.cpp を作成する。
そこで catch.hpp と、 mul2() を実装したヘッダファイルをincludeする。
#include "catch.hpp" #include "../HelloCatch2/mul2.hpp"
あとは、適当にテストケースを書いて、TestProjectをスタートアッププロジェクトに指定してから実行すればOK。
もし、他に作成した関数について単体テストしたければ、TestProject以下にcppファイルを作成し、そこで #include "catch.hpp すればよい。
毎回HelloCatch2プロジェクトで作成したヘッダファイルを参照パスで指定してincludeするのは面倒なので、TestProjectのアイコンを右クリックして VC++ディレクトリ->インクルードディレクトリ から、HelloCatch2プロジェクトで作成するヘッダファイルを置くディレクトリを、インクルードパスに指定すると良い。
ある記事で「あなたの話はなぜ通じないか」（ちくま文庫）が絶賛されてた。ここしばらく、卒論の執筆等で「伝わる日本語」を書く・話すことの難しさに悩んでいたこともあり記事を読み終わった後即購入（kindle版がおよそ500円と破格の安さで買えたというのもある）。卒論を書き終わって余裕ができたので2、3日で一気に読んだ。
で結論から言うと、非常に素晴らしい本だった。就職を目前に控える今、この本が読めて心底良かったと思っている。恐らく今後の人生で何度か読み返すことになるだろう。
この手の本にありがちなのは、小手先だけのテクニックをひたすらに紹介すること。「理科系の作文技術」、「数学文章作法」に代表されるような文書執筆のハウツー本等ならそれでもよいが、会話はそうはいかない。個人的な考えではあるが、目の前にいる相手に対して小手先だけのテクニックを使って物事を伝えては、相手を思う通りに動かしてやろうという浅ましさが前面に出てしまい、相手に伝えたいことを伝えられないどころか、嫌悪感を与えてしまいかねない。
本書では、作者の実体験に基づいた、物事を伝えるために必要となる心構え・考え方を丁寧に説明し、その後で「伝わる」会話のテクニックを教えてくれる。そのため本書を通じて小手先だけのテクニックではなく、血の通った、相手に嫌悪感を与えないような会話術を得ることができる。
本書で一貫して言われていることは、「自分のメディア力を上げる」ことこそが話が通じる一番の基礎であるということ。その例として……
ついに宇宙とコンタクト（日本経済新聞）
ついに宇宙とコンタクト（東京スポーツ）
いかがだろうか？右の二つは同じことを言っている。でも違う意味にみえてしまう。
―『あなたの話はなぜ「通じない」のか』
本書冒頭より引用。こう明快で面白い例を出されると「ちょっとこの本を読んでみるか」と思わされてしまう。
「メディア力を高める」というと、今の時代だとSNSで数万以上のフォロワーがいる、相当以上の稼ぎがある……などが思い浮かぶ。しかし本書で言うところの「メディア力を高める」とはそういうことではない。
自分の聞いてもらいたいことを聞いてもらえるメディアになる。
「メディア力を高める」とは、そういう意味だ。少し引いた目で、外から見た自分をとらえ、それを「こう見てほしい」という自分の実像に近づけていくことだ。
―『あなたの話はなぜ「通じない」のか』
SNS全盛の時代、実際の自分以上に自分を良く見せようと見栄を張ったりしがちである（もちろん私自身も）。見栄を張っていると、外から見た相手があなたに抱く期待値は実際以上のものとなり、結果それ以下のパフォーマンスしか出せないあなたは幻滅されてしまう。
見栄を張らず、等身大の自分を相手に見せていれば、相手はあなたに過度な期待はしなくなる。相手の期待に沿うパフォーマンスを発揮できれば、あなたへの信頼は高まり、新たな仕事を貰える。これを繰り返していけば、「あの人なら間違いない」と思ってもらえ、自然とあなたの発言の影響力は強くしていける。
ただし、ただ仕事を黙々とこなせばよいわけではない。周囲からみて、あなたがどう仕事をしているのか見えていなければ、周りは憶測であなたの仕事を評価してしまう。
伝えなきゃ、伝わらない。
―『あなたの話はなぜ「通じない」のか』
周りに自分を正当に評価してもらうには、自己発信が不可欠だ。あなたの仕事ぶりを理解してくれている人は、あなたの発言・意見に真摯に耳を傾けてくれる。
この話は私に非常に刺さった。就職を目前に控える今、この後会社の戦力になれるのかどうか不安になっている。この不安を紛らわすために、実際には出来ないことを「出来る」と見栄を張っていたことは否定できない。それでは後々、自己評価と他者からの評価、出来ることとやりたいことの乖離に苦しめられることに気づけた。焦ることなく、見栄を張らず、やれることを少しずつ広くしていけるようにしていきたいと思う。
自問自答を粘り強く繰り返すと、いずれ「あ、そうか！」という発見、つまり「意見」を見つけることが出来る。これこそが考えるという作業なのである、と本書では解説している。5W1Hを意識して、ちょっと頑張れば手が届きそうな「問い」をいくつも洗い出せば、問題をほぐしていける。
こうした「問い」を鍵にした「考える」テクニックとして、自分にインタビューするように考えを進める、という手法を提案している。インタビューは「問い」を投げる順番や構成を工夫しなければならない。いい「問い」を見つけるための考え方や訓練方法は第二章で色々挙げられている。
正論を拒むのは、人間の本能かもしれないと私は思うようになった。正論は強い、正論には反論できない、正論は人を支配し、傷つける。人に何か正しいことを教えようとするなら、「どういう関係性の中を言うか？」を考え抜くことだ。それは、
正論を言うとき、自分の目線は、必ず相手より高くなっているからだ。
― 『あなたの話はなぜ「通じない」のか』
最近私は、間違っていることをキツめの言葉で指摘することが多い。幸いなことに、それが原因で人間関係がこじれたということはないが、新生活を始めるにあたって、このままでは良くないことに気付かされた。
信頼関係を築けていない人から、上から目線で指摘されるのは不快なことだ。こちらの都合を全く無視した正論は相手の心を打つことはない。
「共感」を入り口とした意見・コミュニケーションは、正論と比べてずっと相手の感情に届く。「共感」とは、相手と同じ目線で物事を捉えるということ。同じ問題意識を持ち、同じような責任感を持ってくれる人との間で生まれる連帯感は、意見を伝えることに大いに役立つ。
今後正論を言いたくなるときは、一呼吸おいて、「なぜ」相手はそう考えるに至ったのか、冷静に考えるようにしたいと思う。また、自身の意見を言う際には、相手を傷つけることなく、さりとて、嘘やごまかしはせずに言い回し等を工夫して伝えるようにしていきたい。
研究室生活を送る中、教授には「プレゼンはとにかく認知負荷を下げろ」と言われ続けてきた。本書を通じてその言葉の真に意味するところがわかった気がする。認知負荷の高いプレゼンは、そのデザイン・レイアウトが良くないだけでなく、プレゼンしたい内容についての自問自答が不足していて、それを相手に理解してもらえるほど自分が理解していないのだ。このようなプレゼンを続けていては、自身の信頼、本書で言うところの「メディア力」は欠損していく一方だ。本書で学んだ相手に伝える技術と、それを鍛えるトレーニング方法を実践して、自分の言いたいことを嘘偽りなく、素直に相手に伝えられるようにしていきたい。
3回目となった読書振り返りシリーズ。年明け以降、海外に出張したり、学会発表したり、引っ越しの準備をしたり、卒論を書いたり……と忙しい日々が続いていたため、ここ2ヶ月はあまり読書できていない。そのため、もう一ヶ月読み溜めてから本記事を投稿しようと思っていたが、2年以上毎月ブログ更新を続けているのに、今月は（ブログに書ける）ネタが無いため、今月この記事を投稿することにした。 [:contents]
前回の記事はこちら↓
オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング)
研究室に転がっていたので読んでみた。といっても今の自分が読むにはかなり厳しかったので、下に挙げる記事で推奨されていた3、6、11章あたりをつまみ読みしただけ。
古典的名著として知られているだけあり、これまで読んできたプログラム設計に関する記事・書籍の元ネタになっているような話題・用語が散見された。特に「第3章 モジュール性」はこれまでぼんやりとしか捉えていなかった「よいモジュール」とはなんぞや、というのが言語化されていてためになった。「第11章 契約による設計」はC++23以降でcontracts が導入されるらしいので、C++23をgccがサポートする頃もう一度読みたい。
また、本著を読むにあたっては以下の記事が参考になった。特に「PHP7で堅牢なコードを書く」は、必見。PHPのコードが理解できない自分でも活かせる知見が沢山。
そろそろドメイン駆動設計を読みたいなぁ。
20歳のときに知っておきたかったこと スタンフォード大学集中講義
2~3ヶ月かけてゆっくり読んでいた本。自己啓発系の本へのアレルギーを取り除こうと思い買った。買って満足できた一冊。今後は「自己啓発系とかw」と、食わず嫌いせずに良い本は積極的に読みたい。ただし○リ○○○が書くようなペラペラな自己啓発本はNOな。
最終章に書かれていた「自分や他人の間違いにもっと寛容で、失敗も学習プロセスの一環だと思えばよかった」というアドバイスが染みた。人生やり直せるならこの本を高校時代、あるいは大学1年の頃に読んでおきたかった。
超有名なSlideshareで公開されているスライドデザイン資料の書籍版。お試しで入ったkindle Unlimitedで読めたので、移動中の高速バスで読んでいた。まぁわざわざ本を買うまではしなくていいと思う。ただ、○ソデザインなスライドをPowerpoint、Keynoteで作る人を教育する目的で買い与えるのは良さそう。
www.slideshare.net
横井軍平ゲーム館: 「世界の任天堂」を築いた発想力 (ちくま文庫)
今回のオススメ枠。旅先の梅田の本屋で見つけて即買いした本。「枯れた技術の水平思考」で有名な任天堂の横井軍平氏のインタビューをまとめた記事。これと岩田元社長のインタビューまとめ本をあわせて読めば、任天堂がなぜ世界的企業にのし上がったのかがわかる。
全てを一人でやらず専門家の集団を作ればより良いものが作れる、全体を見渡せる知識を持っておく、最新技術を使いたがる技術者のエゴ・プライドを捨てるなど、非常に多くのことが学べた。これをゲームPGとして就職する前に読めたのは非常に良かった。
今回は4冊。最近は技術書ばかりを読むのではなく、ビジネス書も読むようになってきた。色々と学びがあり、食わず嫌いは良くないなとしみじみ。就職してからも週1冊程度のペースで読書していけると良いなぁ。
最近は大学卒業間近で引っ越し準備を進めなければならない&来週学会発表が控えていることもあり、非常に忙しい日々が続いている。ただ、大学の仕事に追われ続け苦しい日々が続いているというわけではない。Prime Videoで鬼滅の刃を見たり、本を読んだり……。また、年始にはインド・コルカタで開催された国際学会に参加した。
結局ホテルの飯をば pic.twitter.com/16iJbV3iWJ
— ai (@ai_9684_dct) 2020年1月5日
レインボーブリッジです pic.twitter.com/ltmMWJBKbT
— ai (@ai_9684_dct) 2020年1月6日
— ai (@ai_9684_dct) 2020年1月6日
山手線です pic.twitter.com/NA1Yusws8n
— ai (@ai_9684_dct) 2020年1月6日
渋谷スクランブル交差点です pic.twitter.com/CSYyVymDQL
— ai (@ai_9684_dct) 2020年1月6日
はとバスです pic.twitter.com/7lHaqtMUC2
— ai (@ai_9684_dct) 2020年1月6日
— ai (@ai_9684_dct) 2020年1月7日
今回のコルカタ旅行で一番クレイジーだったのは普通に混雑している道を馬車で突っ走ったこれ pic.twitter.com/59JbhjdBGP
— ai (@ai_9684_dct) 2020年1月7日
遊んでる画像しかねぇ……
実はこれが自身初の海外旅行。まさか人生初の海外がインドになるとは夢にも思っていなかった。助手という立場での参加であったこともあり、気楽に街の中を丸一日観光していられる程には楽しむことができた。
雑談終わり。
冒頭でも触れたが、現在地方駅弁大・工学部の大学四年生の私は、今年の３月に卒業予定である。国立大の理系というと、一般的に大学院に進むことが多い（例：岐阜大学の機械工学科は大学院進学率8割超え）。そんな中私が就職という選択をとったのは、ひとえにゲーム会社に内定を頂けたからである。
入学時点でゲーム会社への就職をひとつの目標としていた自分が、学部時点でゲーム会社に内定を頂いてしまってはそりゃ大学院進学という選択が消えるに決まっている。
就職という選択自体に後悔はないし、なんなら研究室配属直後はみんな大学院なんか行かずに就職すればいいのにと思っていた。しかし、1年間通して研究に取り組み、何度か学会に参加した今、考えは変わっている。
ほぼ全ての理系大学生は、大きな理由がない限り大学院に進むことを勧める。
研究とは本来何年もかけて一つのことを追求してようやく成果を得られるもの。それなのに素人の大学生が一年間で成果を得ることは困難である。実際自分も、今取り組んでいる研究は中途半端なまま、まだ顔も知らぬ後輩に託さねばならないことが確定している。おまけに就活は、一般的に研究室正式配属前の大学3年の冬から始まるそんなズブの素人を「高度な理系教育を受けた人材」として企業は採用してくれない。理系として評価してもらいたいのなら、基本的には、大学院に進まねばならない。
大学院に進むメリットはまだある。国際学会を始め、個人ではまず行けないところに、大学のお金で参加することができる。
当然学会に参加するには、事前に険しい研究生活と論文執筆を、授業を受けながら続けなければならない。だが、学会に参加することで、貴重な体験をすることが可能だ。
（ちなみに学部生ながらインドの国際学会に連れて行ってもらえたのは人手不足など色々複雑な事情がありまして……）
よく言われることだが、研究室選択で重視すべきは、「研究テーマ」よりも「教授の人柄」である。これは他の研究室に配属された同期の話を聞いてしみじみ感じている。
全くもって興味の持てない研究なら別だが、多少なり興味がある研究テーマで、人柄の良い教授の研究室と、研究テーマに非常に興味があるが人柄最悪の教授の研究室を比較すれば、選ぶべきは前者だ。教授の性格が悪いと、いくらやりたい研究でも人間関係で悩まされ、高いモチベーションを保つことができない。
なお、研究室配属前の学部生が勘違いしがちなのは、教授が熱心・講義が厳しい=ブラック研究室だと思ってしまうことである。これは必ずしもイコールではない。熱心なのは、面倒見が良いからだったりする。拘束時間が長いと思っているのは、単に所属している学生が高いモチベーションで研究に取り組んでいるだけなのかもしれない。私は時々「研究室が辛いー」だの「論文修正が終わらない」だのでぼやいているのは、いい意味で教授の面倒見がいいせいである。
ちなみに、個人的なブラック研究室の基準は、
教授の性格最悪・拘束時間長い > 教授が学生の面倒をほとんど見ない放置系研究室 > 拘束時間が極端に長い研究室
放置系研究室は非常に厄介。他所から放置系であることに気づくのは困難であり、かつわかり易いパワハラを受けているわけではないので大学に通報しても中々動いてもらえない。放置系研究室を避けたければ、事前に教授ではなく所属している学生に話を聞くべきである。
色々言ってみたが、所詮私は学部で卒業する人間。大学院に進むか悩んでいる人は、実際に大学院生に話を聞いてみたりするべき。これから研究室配属が待っている後輩らが良い研究室に配属され、満足いく研究生活が送れることを祈ります。
月1更新のノルマをすっかり忘れてたのでFGO特番が始まるまでのこの時間で急いで更新。
ゲームグラフィックだったりGPUだったりを日本語で調べると必ず一度は目にすることになる西川善司さんの最新作。実はまだ半分くらいしか読めていない。
3Dゲーム黎明期から始まりDirectX12世代までの技術を一通りかいつまんで学べる。数式は殆ど出てこないので読みやすい方だが、ある程度バックボーンとなる知識がないと理解は困難。CGエンジニア検定のコンピュータグラフィックスあたりを読んでからこの本に手を出すとちょうど良い。読み切ったら高いけどリアルタイムレンダリングに手を出そうと思う。
![コンピュータグラフィックス [改訂新版]](https://images-fe.ssl-images-amazon.com/images/I/51y88JWRCqL._SL160_.jpg "コンピュータグラフィックス [改訂新版]")
リアルタイムレンダリング 第4版 (Real Time Rendering Fourth Edition 日本語版)
FACTFULNESS(ファクトフルネス) 10の思い込みを乗り越え、データを基に世界を正しく見る習慣
大学に入ってから、CS系の技術書と漫画ばかり買い漁っていて、売れ筋のビジネス書（ホリ○モン）とかクソとか思っていたのだが、気が向いて買ったFACT FULLNESSが面白くて、ビジネス書にも手を出せるようになったのは成長。この調子で技術書ばかりではなく小説等もたくさん読んでいきたいなあ。
技術書はこの二ヶ月大量に買ってしまったので、暫くは積ん読消化フェーズ。そんなこと言いつつ3月4月にまた新しい本買いそう。ゲーム系やPG言語の解説書だけでなく、OSなど低レイヤの本や、数学系の専門書にも手を出していきたい。
