サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
パリ五輪
yfakariya.blogspot.com
この記事はC#アドベントカレンダー2020その2の6日目のはずです。 その昔(*1)、Rico Marian(*2)は言いました。「CLRがfloatまたはdouble型を基になる型として使用する列挙体をサポートしていることをご存知でしたか?」と。 ご存知のように、C#では列挙体の基になる型としてはプリミティブの整数値しか認めていません。具体的には、byte、sbyte、short、ushort、int、uint、long、ulongです。 Ricoが言うように、C#ではfloatやdoubleをサポートしていません。 さらに、Ricoは「これはECMA標準です」と言っています。 11年前の私はわざわざ検証しませんでしたが、このあたりを深堀していこうと思います。 floatやdoubleを基になる型にする列挙型を定義してみる念のため、以下のようなC#コードを書いてコンパイルしてみます。 p
(なんかこのネタ、誰かがやってそうな気がしつつ) 一部ではバージョンがわかりづらいなどとも言われている .NET Core の起動の仕組みについて、適宜ソースコードを眺めつつ、整理したいと思います。私は中の人ではなく、コードを解析しながら書いているので、おかしな点がありましたら twitter 等で教えていただけると嬉しいです。 構造 ご存知のように、.NET Core は、コンパイル結果の実行可能アプリケーションまたは dotnet コマンドから実行します。 その時の動作の流れを図にすると、以下のようになっています。 この図において、長方形はファイル、角丸四角形はレイヤー、青の長方形は説明のためのグルーピングです。 この図の要素を簡単に説明すると、以下のようになります。 dotnet コマンド。別名 .NET CLI と言われているのはこれ(のはず)です。muxer と呼ばれることもあり
この記事は、.NET Core Advent Calendar 2016の2日目です。 あまり目新しい内容ではありませんが、.NET Standard と言われるものについて、いまいち情報が整理されていないように思うので、ここで整理してみようと思います。 結構長くなっていますので、時間のない方は まとめ だけどうぞ。 3 つの .NET Standard 個人的な分類 ですが、.NET Standard と言われているものは 3 つあると思っています。 仕様としての .NET Standard TPM としての .NET Standard TPM(Target Platform Moniker)は、NuGet での対象プラットフォームを表す識別子です。 NetStandard.Library パッケージ 話をするとき、何かの記事を読むときには、今相手がどの「.NET Standard」のこ
この記事は C# Adventcalendar 2013 の記事です。この記事では、ちょっとだけ濃い目に、MsgPack for CLI というシリアライザライブラリで使っている、動的コード生成技術について簡単に解説します。この記事が動的コード生成を組み入れるときの助けになればいいな、と思います。 昨日の @rabitarochan さんの記事は CodeDOM と MEF を使用した、文字通り動的にコードを生成する話でしたが、今日は、もうちょっとライブラリの話にします。といっても、それほど深い話ではありません。 動的コード生成とは 「動的コード生成」と言う用語は、あまりちゃんとした用語ではないと思うので、この記事のために定義しておきます。 ここでは、「プログラムの挙動を実行時に変更するために、実行時にプログラムを生成し、その結果を実行すること」、とします(後々の分類のために、こういう定義
ずいぶんと長い間書いていなかった気がします…… さて、github で週末ちまちま書いていた MessagePack for CLI が、公式のリポジトリに取り込まれました。びっくりです。 MessagePack とは 相互運用可能で、コンパクトなバイナリ形式のオブジェクトシリアル化フォーマットまたはそのライブラリです。詳しくは 公式サイト なり、 @frsyuki さんのブログなどを参照してください。 今回はそれの .NET 用の実装を作った(ている)ということになります。 .NET 用の実装について .NET 用の実装は実は 3 代目だったりします。初代は @neuecc さんの blog のエントリで使用されているもの。わりとざっくりとした実装で、まだまだパフォーマンスチューニングの余地がある状態でした。 2 代目は NuGet で MessagePack for C# で出てくるも
元ネタは、C#チームのEric Lippert氏のブログの数年前の投稿です。 例外処理というと、「とりあえずキャッチしとけ」とか、逆に「とりあえずキャッチするな(集約例外ハンドラーで対処しろ)」とか言われたりします。かと思えば、「プロなんだから自分の頭で考えろ」とか、「業務フロー次第でしょ」などと千尋の谷に突き落とされたりもします。 極論を言えばそうなのですが、もう少しガイドラインとなるものは無いのか、ということでEricのブログの内容をかいつまんで紹介します。 Ericは、例外は4種類に分類できると言っています[1]。 例外の4分類(Eric Lippert氏による) 種類説明特徴対処方法例 致命的な例外(fatal exception) プロセスに深刻な問題が発生し、今にも死にそうな状態にある場合に発生する例外。 プログラマーの過失ではない[2]、 復旧は無理(finallyを実行する
このページを最初にブックマークしてみませんか?
『yfakariya.blogspot.com』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く