実行コンテキスト
久々に、そのうち http://ufcpp.net/study/csharp/ に載せる前提の下書き的なブログ。 概要 .NET Frameworkのスレッドは、実行コンテキスト(execution context: 実行の文脈)というものを持っています。 「文脈」という言葉の意味するところは、「意識することなく皆が共有している情報」ということです。実行コンテキストの場合は、以下のような情報を、スレッドを超えて共有します。 セキュリティ コンテキスト: どういう権限でそのスレッドが動いているかを伝搬して、適切なセキュリティを保つ 論理呼び出しコンテキスト: (実際の呼び出しスタック上の上下関係でな く、)論理的な呼び出し関係での情報共有 情報の共有範囲 実行コンテキストを理解するためには、まず、どういう範囲で情報を共有できればいいのかという話をしましょう。 静的フィールド オブジェクトをま
immutable
変数の immutability に関する議論、今に始まった話でもないんでしょっちゅう見かけるには見かけるんですけど、まとめ的な話はあんまりきれいにまとまってるところ見かけないなぁとか思ったり。 というので、まだそんなにきれいに整理できてるわけでもないけど、ちょっと書いてみる。 値の不変性 値の不変性にもいくつか種類があって、 constant： コンパイル時定数に名前を付けておきたい 扱いが完全にリテラルと一緒になるやつ C# の const C++ の場合、#define の代替としての const ようは、パフォーマンス的な話で、コンパイル時に解決できる値は全部コンパイル時にやっちゃいたいって話 ぶっちゃけ、リテラルが定義できるようなものだけ const 付けれればいいのかなぁと C# の場合、整数型と string と enum だけが const になれる C++ は逆に、con
株式会社ロングゲート - プログラミングの魔導書 ～Programmers’ Grimoire～ vol.3
プログラミングの魔導書 〜Programmers' Grimoire〜 Vol.3 “Parallel, Concurrent, and Distributed Programming” 並行世界の魔物に人類はどう立ち向かうのか。 目次(カッコ内に数字のある記事名についてはサンプルをご覧いただけます) 序文 熊崎 宏樹 Lock-free入門 (1 2) 熊崎 宏樹 OpenACC 藤田 典久 ErlangとScalaにおけるアクターモデルの紹介 (1 2) 幾田 雅仁 C#の非同期処理 岩永 信之 Real World STM ～作って学ぶSTM～ 石井 大海 データ並列への招待 (1 2) shelarcy 合成可能なメッセージパッシング ～Concurrent ML の紹介～ 小笠原 啓 コルーチンスタイルプログラミング 高橋 晶 画像検索入門 miyabiarts 購入 PDF 版
Microsoft Corporation
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
第1回 いよいよWPFの時代。WPFの習得を始めよう
Visual Studio 2010の開発サポートや標準機能の充実で本格的な実用が進むことが期待できるGUI技術の「WPF」。WPFを基礎から学べる連載スタート。 連載目次 WPF（Windows Presentation Foundation）は.NET Frameworkに含まれるプレゼンテーション層技術（GUI開発ライブラリ）である。 WPFはバージョン3.0以降の.NET Frameworkに標準搭載されている。それより前のGUI開発ライブラリであるWindowsフォームが、単にWin32 APIをマネージ・コードでラップしたものであるのに対して、WPFはマネージ・コードで新たに実装されたGUI開発ライブラリであり、豊かなユーザー体験を提供する先進的なGUI開発基盤である（詳細後述）。 .NET Frameworkが3.0、3.5、4とバージョン・アップし、WPFはすでに3世代目を
非同期処理の基礎知識
「CPUとかOSレベルな話から」という意味で「基礎知識」。べたに、「『こう書け』とだけ言われても、中の仕組みを知らないと納得いかないですよね」という話。 CPUの構造がどうとかいう話だけとか、OSスレッドの話だけとか、I/Oの話だけとか、個別にはちらほら見るものの、非同期処理って観点からこの辺りを通して説明してる資料って少ないなぁと常々思っていたので。「こう書いた方がいいよ」事例サンプルはC#ですけども、他の言語、他のOSでも通じる話だと思います。 ぶっちゃけ、C# 5.0のasync/awaitを使うとほとんど内部で解決してくれるような話ではあります。ただ、もちろん、「async/await使えば同期っぽく書けるといっても、非同期特有のはまりどころにははまるでしょ？」といわれるとその通り。でも、じゃあ、非同期処理を避けれるかというといまどき無理な話で、「非同期処理が避けようないんだったら
INotifyPropertyChanged の実装
追記： 色々更新した 前々から気になってはいたんだけども。 MVVMパターンのViewModelで、INotifyPropertyChangedをいちいち実装すんのかったるい。かといって、AbstractなViewModelBaseは継承したくないでござるよ。 ちょっとイケてるINotifyPropertyChangedの実装 今の C# だと、手書きだけで INotifyPropertyChanged の実装をうまくやろうと頑張るのは厳しいと思うんですよね。コードスニペット使うのを前提に考えるのが一番いい妥協だと思います。 ということで、以下のようなものを作成。 ヘルパークラス（C#） とりあえず同じプロジェクトにぶち込むなりライブラリ化するなり コードスニペット マイドキュメントの下の、Visual Studio のフォルダー以下、Code SnippetsVisual C#My Co
nullが生まれた背景と現在のnullの問題点 ― null参照問題（前編）
Cの系譜を継ぐC#ではnullが長らく使い続けられてきたが、最近ではその存在が大きな問題だと認識されている。前後編でこの問題を取り上げ、今回（前編）はnullを取り巻く事情について考察する。 ← 前回 連載 INDEX 次回 → 近年、nullの存在は、billion dollar mistake（10億ドル規模の損失をもたらす過ち）と呼ばれるくらい忌避されるものになっている。 nullは、低コストでそこそこ安全に参照を扱えるという意味で悪くない妥協ではあるが、技術が進歩した現在ではもう少し賢い参照の扱い方があるはずである。C#のように、これまでnullを認めてしまっているプログラミング言語で、今からそれを完全になくすというのは現実的ではないが、nullに起因する問題を少しでも避ける手段はこれからでも追加していけるだろう。 今回は、nullが生まれるに至った背景から始め、nullが抱える問
Microsoft Corporation
Microsoft Learn. Spark possibility. Build skills that open doors. See all you can do with documentation, hands-on training, and certifications to help you get the most from Microsoft products. Learn by doing Gain the skills you can apply to everyday situations through hands-on training personalized to your needs, at your own pace or with our global network of learning partners. Take training Find
C# Design Notes / デザイン プロセスについて
Roslynプロジェクトで、GitHubへの移行後初の「C# Design Notes」が公開されたみたいです。 https://github.com/dotnet/roslyn/issues/98 「続に言うC# 7」(順調に行けばC# 7になるであろうもの)に関する話題も初お目見え。単に「こんな仕様を考えています」という話出はなくて、仕様決定プロセス自体をもっとオープンにしていく話や、どういうテーマを持って決めていこうとしているのかという話が含まれています。 今出ている「新機能候補」については、どうせ変わるだろうし、さらっと流す感じで。ここでは、どちらかというと、デザイン プロセスとかテーマの話を中心に軽く和訳しておこうかと。 とりあえず、デザイン プロセスに関する話を書いてたら、気が付いたら全訳してた。今日はここまで（C# 7 で取り組むテーマや、具体的な機能案の話は後日）。 以下、
C# Design Notes / テーマ
一昨日(C# Design Notes / デザイン プロセスについて)に引き続いて。C# 7がらみの話の続き。 一昨日はどういうプロセスでC#の仕様が決まっていくかという部分について説明(というか、全文和訳)しました。 今日は、C# 7(に向けた、6リリース後)のC#のテーマについて。C# Design Meeting Notes の 2. のところに書かれている内容の概要になります。 背景 C# 7どころか、C# 6もまだリリース前なわけですが。昨年末にC# 6の仕様はfixしてリリース準備に入ったとはいえ、7はだいぶ先の話です。これまでの周期から考えると1・2年先になるのかなぁ。 つまり、だいぶ早い時期からオープンなディスカッションをしようとしている。今ならアイディア出し放題、C#チームの出してくる案にもコメント付け放題。(こういう場、特に英語ですし、苦手な方でも、いずれ、UserV
C# 7に向けて(1): 変数やフィールドの書き換え
プログラムを書くときに、「値が書き変わらないことの保証」(不変性)がほしいことは結構あります。 C# だと、現状(6も含めて)では、const 修飾と、フィールドに対する readonly 修飾くらいしかなくて不便に思うことがありました。 もちろん課題があるからこそのこの現状なんですが、C# 7では、「less ambitious」（野心を抑えて。妥協的）でも、もう少し不変性の保証を増やそうという提案がされています。 Proposal: ‘readonly’ for Locals and Parameters #115 Proposal: Immutable Types #159 readonly は「浅い」不変性 「変数や引数にもreadonlyを付けれるようにしてくれ」という要望は昔からあるものの、これまでやらなかった理由は単純で、そこまで有用でもないから。有用は有用だと思うんですけど
C# 7に向けて(4): C# 6に漏れた分
元々、C# 6として(Visual Studio 2015と同じスケジュールで)入る予定だった機能のうちのいくつかは、期間的な問題でいったん仕様から外れました。そのうちいくつかは本当に単なる工数の問題で、ほぼ当時の仕様そのままに、C# 7に入りそうです。そういった類の機能に関する話も、今日、GitHub 上の issue 化されました。 Proposal: Binary literals #215 Proposal: Digit separators #216 Proposal: Declaration Expressions #254 あと、InternalImplementationOnly 属性ってのが、追加で(こちらはC# 6に間に合わせて)入りそうです。 Add support for InternalImplementationOnly attribute #220 もう1個、
async/awaitと同時実行制御
C# 5.0のasync/awaitを使うと、多くの場面ではシングル スレッド的な動作になるし、多くの場面ではlock不要（結果的に、デッドロックが起こりようなくなる）になったりします。 ただし、「多くの場面で」。「必ず」ではないのがはまりどころ。いくつかの場面では、同時実行制御が必要です（普通にマルチスレッドの平行実行になるので、同時に同じデータにアクセスされる可能性を考慮しないとバグります）。 前提知識 いくつか、C# 5.0世代の非同期処理についての前提知識は、以下のスライド（先月末の.NETラボでの発表）を参考にしてください。 5~12ページ: async/awaitの書き方 17~22ページ: スレッドとそのコスト 24~26ページ: スレッド プール 29~32ページ: I/O完了待ちと非同期API 36~40ページ: UIスレッドとディスパッチャー 41~45ページ: 同期コ
C# 7に向けて(5): Record types
現時点ではC# 7の目玉になるであろう機能として、pattern matching と record types があります。 Proposal: Pattern matching and record types #206 C# 6の機能提案の段階で出てきてはいたものの、期間的な問題で「7送り」になりました。当時と比べて、record types の書き方が少し変わっています。 長くなりそうなので、record types と pattern matching の説明は2回に分けようかと思います。今日は record types の話。 最小限の例 値の書き替えってどのくらいの頻度でやりますか？ 僕の場合だと、自分が書くクラスの半分以上は書き換え不能(先日書いた内容で言うところの immutable)に作っています(参考:C# 7に向けて(1): 変数やフィールドの書き換え)。「めんどく
C# 7に向けて(6): Pattern matching
先日の続き、C# 7の目玉になるであろう機能、pattern matching と record types Proposal: Pattern matching and record types #206 の片割れ、pattern matching の話。 昨日の record types (もう、自分が書くクラスの7割くらいは record types で書くことになりそうな勢い)と比べると出番は少ないでしょうが、なかなかに便利そうな機能です。 マッチング構文 以下のような感じで、オブジェクトの型や値のマッチングを、再帰的に行う構文が追加されます。 定数マッチング x is 1 定数との比較 下記の 型マッチング x is T t x が特定の型 T の時にマッチ その時、x を T にキャストしたものが t に入る プロパティ マッチング x is T { X is int , Y
C# 7に向けて(7): まだ具体案の見えていないもの
「C# Design Notes / テーマ」で「どういうことがしたいか」だけ列挙されているものの、具体的にどういう仕様を追加するかまではまったく決まっていないものがまだまだ結構あります。そんな具体案の見えていないものに対して、いくつか、issue ページができて、オープンなディスカッションを始めたようです。 あと、Issue に対してマイルストーンも切り始めたみたいで、「milestone: “C# 7 and VB 15″」で検索すると一覧が出てきます。 [Proposal] Support System.Delegate as a generic constraint #158 Proposal: bestest betterness #250 Proposal: Declaration Expressions #254 Proposal: support await in Catc
C# 7に向けて(8): Tuples
C# 7 Proposals な内容、あと Method Contracts だけになったと一息ついたところで、新しい Issue ページが立つわけですが。 Tuples #347 タプル、つまり、型名を持たない構造化データ/データの一時的なグループ化の話。 これは結構気合の入った提案文章になっているので、全訳気味に紹介。 System.Tuple のおかげでタプルという言葉だけではあまり期待感が持てないかもしれませんが、C# 開発者的にインパクトのある言葉で表現すると「アセンブリをまたげる匿名型」「メソッド引数・戻り値やフィールドに使える匿名型」です。 背景 「複数の値の一時的にグループ化」が必要な最もよくある例は、メソッドの引数リストでしょう。C# をはじめ、多くのプログラミング言語がこれをサポートしています。要するに、複数の引数を持つメソッドには、F(1, “abc”) というように
C# Design Notes 2/4版
新しいC#デザイン ミーティング議事録。 C# Design Meeting Notes for Feb 4, 2015 今回の議題は3つ。大きいのは3つ目の Classes with values です。タプルと関連してのレコード再検討。 あっ、あと、おまけで。Roslyn の RC1 を NuGet 公開したそうです。 Internal implementation only 前にC# 7シリーズその(6)で触れた、 ImternalImplementationOnly 属性に関して、もう少し詳細な検討。 問題点に関しても前の issue ページより少し詳細に。そして、今でもできること、コンパイラーに機能追加すればできること、.NET ランタイムにも手を入れるならみたいな話と、それでどのくらい「穴」が改善するかという話がかかれています。 問題はインターフェイスに後からメソッドを足しにく
C# 7に向けて(9): Method Contracts
今 issue ページができてて大きめのものはこれが最後のはず。Method Contracts。メソッドに対する「契約」。 Proposal: Method Contracts #119 結構長かった… 結局、全9回に。今後は、「週刊ブログ」程度でよくなるはず。きっと。 契約プログラミング そもそも「contracts」とは何か的な話は、昔書いたスライド貼って済まそう。 (補足: このスライドでは非null制約を例に挙げて説明していますが、非null制約は契約でやるよりも、「非null参照型」を作る方がいいと思います。C# 7向けの提案の中にはこの「非null参照型」も含まれています。) 一応、.NET 4の頃から、ライブラリとツールでのサポートはありました。 This file contains bidirectional Unicode text that may be interp
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
