結論から言うと、C#のInternalsVisibleToAttributeでは
using System.Runtime.CompilerServices; [assembly: InternalsVisibleTo("ConsoleApp.Tests")]
上記のような指定をします。
本来アクセス出来ないものにアクセス出来るようになるのでユースケースとしてはテストコードかなと私は思ってます。
とはいえ、きちんとpublicとinternalの使い分けをしているプロジェクトはありますが、場合によってはinternalはあまり使われてないこともあります。
これがprivateまでアクセスできるなら、もっと使えると思うのは私だけですかね。
privateのメソッドをアクセスしたいなら、Reflectionを使うことになります。nameofも使えるのである程度、融通は利きますが、引数が変わるのには追従されないので、そこまでは私はやってませんね。
後輩とゲームのスクリム（練習試合）に参加する予定だったのですが、その後輩が遅刻してしまったのです。
そこで会社の後輩が取った行動が、Gifteeでコーヒーを贈ってくれたのです。
若い人は、こういうサービス使っているのかと感心しました。
これなら相手の住所を知らなくても贈れます。
特にコロナのご時世ですから、いいですね。
ただ、使えるギフト券が充実して欲しいところです。
特にコンビニで使えるギフト券。
ミニストップで使えるギフト券もあるのですが、ミニストップって近くにないんですよね。
なので、気軽に贈れて使ってもらえそうなのがローソンのギフト券くらいになってしまいます。
RapidJsonはC++のJsonパーサーです。Tencentによるオープンソースとなっています。
GitHubのページにも書いてありますが、特徴としては
特に一番最後のヘッダーファイルのみという点が特徴的です
RapidJSON is a header-only C++ library.
なので、導入がしやすいです。include指定のみでOKですから。
C++だとNuGetで取得できてもプロジェクトに依存ライブラリなどの指定する必要がありますが、これについては追加のインクルードファイルのみの指定ですみますから。
では、導入してみます。
NuGetでRapidJsonをインストールもしくは、パッケージマネージャーコンソールで以下のようにコマンドを入力します。
Install-Package RapidJson
プロジェクトのプロパティにて追加の依存インクルードディレクトリにて以下を指定します。
$(SolutionDir)packages\rapidjson.1.0.2\build\native\include\rapidjson
※1.0.2の部分は取得したバージョンによって修正してください。
軽く試すのであれば、リポジトリのREADME.mdのUsage At Glanceに書いてあるページを試すといいです。
// rapidjson/example/simpledom/simpledom.cpp` #include "rapidjson/document.h" #include "rapidjson/writer.h" #include "rapidjson/stringbuffer.h" #include <iostream> using namespace rapidjson; int main() { // 1. Parse a JSON string into DOM. const char* json = "{\"project\":\"rapidjson\",\"stars\":10}"; Document d; d.Parse(json); // 2. Modify it by DOM. Value& s = d["stars"]; s.SetInt(s.GetInt() + 1); // 3. Stringify the DOM StringBuffer buffer; Writer<StringBuffer> writer(buffer); d.Accept(writer); // Output {"project":"rapidjson","stars":11} std::cout << buffer.GetString() << std::endl; return 0; }
このソースコードではstarsの値10を取得して、加算して、出力するという処理をしています。
最近、Twitterを見ているとnoteでブログを投稿されている方をちらほら見かけます。
私は、この通り、はてなブログを使っているわけで、特に不満もないのです。
しかし、常に新しいことをする、新しいモノを触っていないと、気づいた時には時代遅れの可能性もあることは、よく思い知らされているので、軽く触ってみることにしました。
画面全体のデザインとか見ていると、確かに今っぽい親しみやすいデザインですね。
Web上の記事を見ているとnoteの良いところとしては、
といったところでしょうか。
人によっては確かにどちらも大きなメリットですね。
ただし、デザインは固定になっています。
自分としては少し人と違ったデザインを使いたいのが本音。
と言ってもスマホで見ると同じですし、Webに使っているテーマは気に入っているものの、やや見づらいのですが。
それでもこのタイプフェースで書いてみたいんだという思いでテーマを選んでいます。
では、早速ブログを書いてみることに。
当たり前の話なのですが、はてなブログとは違いますね。
画像貼り付けについてはできますが、はてなブログのように画像アップロード中なのがわかりづらいです。
残念だったのが、Markdownが使えない点。
方法はあるにはあるのですが、はてなブログに慣れている身からするとうーん……。
１記事くらい投稿してみようとPMJLシーズン１が開幕したことについてつらつら書いてみようと思ったのですが、断念しました。
というわけで、今の私は、はてなブログのままでいいかなという結論になりました。
プライベートのPCはMacでPararells Desktop上でWindowsを動かしているため、CLionとResharper+Windowsを比較してみました。
あくまでも個人的な感想ですが使い勝手としては、Visual Studio 2019 + Resharper + Windowsの方が良いです。
Windowsも動かせるとはいえ、Macで済むならMacのみの方がいいため、Mac + CLionで C++のコードを書いていました。
しかし、どうもコード支援が弱く、ここでは、こういうコード支援して欲しいなあと思うことがしばしばです。
C++って、安全ではない静的な片付け言語という立ち位置だから仕方ないのかなあと思っていました。
しかし、Visual Studio 2019+Resharperだと割とここはコード支援もらえないのかということがあまりなく、コーディングがサクサク進みました。
Mac + CLionですと、cmakeファイルを宣言する必要があります。
Windows + Visual Studio 2019ですとNuGetとプロジェクトのプロパティが済むので、こちらの方が手軽にライブラリを導入できるのも良い点。
LNK2019 未解決の外部シンボル impglewBindBuffer が関数 "public: thiscall VertexArray::VertexArray(float const ,unsigned int,unsigned int const ,unsigned int)" (??0VertexArray@@QAE@PBMIPBII@Z) で参照されました
以下の記事に助けられました
GL/glew.hを宣言する前に#define GLEW_STATICを実行する。
#define GLEW_STATIC #include <GL/glew.h>
プリプロセッサで定義してもいいようです。
