C# 8.0 の予告 | ++C++; // 未確認飛行 C ブログ
一昨日、C# 8.0 に関するブログが出たわけですが。 Building C# 8.0 個人的には「最近全然ブログ書かない C# チームが働いただと…」的な感想もあるんですが (C# 7.3 のときとか「半年前にリリースしてたわ」みたいなブログでした)。 近々プレビュー版が公開されるであろう C# 8.0 の予告記事です。 Visual Studio 15.9 正式リリースに続いて近々、Visual Studio 16.0 のプレビュー版も公開されて、 それと一緒に .NET Core 3.0 と C# 8.0 もプレビュー公開になると思われます。 .NET Framework 4.8 は未サポート？ で、「.NET Framework 4.8 は .NET Standard 2.1 に追従しないので、C# 8.0 に対応しない」みたいな感じのことが話題になっていますが。 これ、多少不正確
例外処理(Windows PowerShell)
概要 PowerShell では throw で例外を投げて、trap で例外を処理します。 シェルスクリプト言語の割には例外処理がきっちりしていると思います。 （微妙に挙動がつかめないところもあるんだけど・・・。 外部スクリプト内で 0 除算（1/0 とか）すると例外が trap できなかったり。） PowerShell では、（タイプミスしたりして）未定義のコマンドを入力したり、 不正な型変換をしたり、0 除算したり、 なんらかのエラーが起きたとき、例外を投げます。 例外は、特に何もしなければ、例外の内容を赤字で表示します。 > UndefinedName 用語 'UndefinedName' は、コマンドレット、関数、操作可能なプ ログラム、またはスクリプト ファイルとして認識されません。用 語を確認し、再試行してください。 発生場所 行:1 文字:13 + UndefinedNam
ビルドで使う C# コンパイラーを差し替える
Visual Studio 2017 15.5で、C# コンパイラーのコード生成の仕方がちょっと変わりました。 その余波で起きる問題を回避するために、Visual Studio は 15.5 のまま、C# コンパイラーのバージョンだけを下げる方法について話します。 背景 C# コンパイラーが出力するコードのどこが変わったか 15.5 の世代では、とにかくいろいろパフォーマンス改善を行っています。 .NET Coreのランタイムや標準ライブラリのパフォーマンスも1～2割上がっています。 Visual Studioも、ソリューションのロードにかかる時間が半減していたりします。 C# コンパイラーも、コンパイラーが出力するコードがより速くなるように微妙に調整が入っています。 コンパイラーの出力結果なんですが、今まで int (符号付き)だったところが uint (符号なし)で生成されていたりしま
[雑記] Dispose にまつわる余談
概要 「リソースの破棄」で説明したように、 C# で何らかのリソースの破棄が必要な場合、IDisposable インターフェイスを実装して、using ステートメントを使います。 この、IDisposable インターフェイス（の Dispose メソッド）の実装方法などに関して、少々注釈を。 IDisposable インターフェイスの実装 .NET の性質上、 明示的に破棄処理を書く必要があるリソースには、非管理リソース（unmanaged resource）と管理リソース（managed resource）の2種類あります。 非管理リソース .NET Framework （の自動メモリ管理）の範疇にないリソースです。 ネイティブ コードで書かれた OS 機能を直接呼び出す場合などです。 例えば、.NET の範疇でも File クラスを使ってファイルの読み書きができますが、 Window
[雑記] 非同期制御フロー
概要 C# 5.0のasync/awaitがなかったころ、少し複雑目な非同期制御フローをどうやって実現していたかという話。 C# 5.0を使えない状況下で非同期処理を書くことになった場合の参考としてや、async/awaitがどうやって実現されているかを知るきっかけになると思います。 サンプル コード（ZIP 形式。proj/sln 含め一式。） ポイント C# 5.0（await演算子）便利だなー await演算子が内部的にやっていることは、イテレーターに近い なので、昔はイテレーターを使って非同期処理をすることが結構あった サンプルの要件 今回の例として使うのは、Figure 1に示すような、確認ダイアログ表示のフロー。 確認ダイアログを表示する例 要は、何かを実行するにあたって、特定条件下では確認ダイアログの表示が必要で、すべてのダイアログで「OK」を押したときにだけ実行に移るという
非同期処理(C# によるプログラミング入門)
概要 注意： 2010年10月時点での CTP （community technology preview）版を元にした記事になっています。 製品版までに変更の可能性があります。 （async や await というキーワードも変更される可能性あり。） Ver. 5.0 スレッドを使った非同期処理を行いたい動機としては、以下の2つが挙げられます。 非ブロッキング処理: I/O 待ちとかで UI スレッドをフリーズさせないようにする 並列処理: マルチコアを活かした並列処理でパフォーマンス向上 このうち、並列処理に関しては、Parallel クラスや Parallel LINQ で簡単に対応可能 （ラムダ式や LINQ を使えば、並列じゃない場合とほとんど変わらず書けます。 参考： 「[雑記] スレッド プールとタスク」）。 一方の、非ブロッキング処理は、今までは結構面倒だったものの、 as
[雑記]動的な処理の使い方
概要 プログラミング言語の区分として、静的（static）か動的（dynamic）かというものがあります。 ただ、動的と言っても、何を動的に行うか、いろんなやり方があって、いろんな用途があります。 C# は「静的な言語」と呼ばれることが多いですが、正確には「静的な型を持つ言語」になります。 そして、型が静的でも、動的ローディングや動的コード生成など、色々な動的処理を行えます。 ここでは、C# でできる動的処理と、その用途について説明して行きます。 動的ローディング 既知の型を、未知のDLLから読み込みます。 例えば、図1のような感じ。 System.Reflection.Assembly クラスの Load メソッドなどを使って DLL を読み込んで、 System.Activator.Create メソッドでインスタンスを作ります。 動的ローディング。 通常の（静的な）コードと比べて、
[雑記] 動的コード生成のパフォーマンス(C# によるプログラミング入門)
概要 .NET Framework のバージョンが上がるたびに色々と追加され、 今や、動的コード生成にもさまざまなやり方が。 ということで、並べて比較してみたいと思います。 「動的 ＝ リフレクション ＝ むちゃくちゃ遅い」というイメージをもたれる方も多いと思いますが、 実際のところ、1度生成したコードをキャッシュしておくなどの工夫をすれば、意外と許容範囲なパフォーマンスが得られます。 （GUI の描画部分やネットワーク通信部分の遅延と比べれば、演算部分の数倍程度の差は取るに足らない場合が多く、 過剰に気にする必要はありません（もちろん、状況次第）。） 比較コード含めたソースコード一式： DynamicPerformance.zip ポイント 毎回リフレクションを呼び出すのはやっぱりかなり（2～3桁）遅い。 キャッシュ機構を使えば、静的なコードの数倍程度までは速くできる。 C# 4.0 の
dynamic の内部実装
概要 Ver. 4.0 dynamic って内部的にはどうなってるの？という話。 C# の dynamic は、「型が動的」というよりは、「静的な型に対する動的コード生成」と言った方が正確です。 動的に生成したコードはキャッシュされていて、2度目の呼び出しからはかなり効率よく実行されます。 このような手法はインラインメソッドキャッシュ（inline method cache）と呼ばれています。 注意： 内部的な話なので、C# のバージョンアップで実装方法が変わる可能性もあります（基本的な原理は変わらないと思いますが）。 （今このページに書かれている内容は、C# 4.0 の時点の実装に基づいています。） ポイント dynamic 型ってのは実はなくて、内部的には object。 CallSite クラスを使って動的コード生成。 動的 callsite dynamic を使ったコードは、内部的
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
