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# Design Notes / デザイン プロセスについて
Roslynプロジェクトで、GitHubへの移行後初の「C# Design Notes」が公開されたみたいです。 https://github.com/dotnet/roslyn/issues/98 「続に言うC# 7」(順調に行けばC# 7になるであろうもの)に関する話題も初お目見え。単に「こんな仕様を考えています」という話出はなくて、仕様決定プロセス自体をもっとオープンにしていく話や、どういうテーマを持って決めていこうとしているのかという話が含まれています。 今出ている「新機能候補」については、どうせ変わるだろうし、さらっと流す感じで。ここでは、どちらかというと、デザイン プロセスとかテーマの話を中心に軽く和訳しておこうかと。 とりあえず、デザイン プロセスに関する話を書いてたら、気が付いたら全訳してた。今日はここまで（C# 7 で取り組むテーマや、具体的な機能案の話は後日）。 以下、
スラスラわかるC#
どうも、自己紹介が「C#でググれ（bingでも可）」の人です。 C#使ってるところなら大体どこに行ってもうちのサイトが開かれてて、「このサイトの中の人です」で自己紹介が完了します。 というわけで、C#の入門本を出します。 スラスラわかるC# サイト内の活動情報のところにも、書籍紹介を追加。 ++C++; 活動情報 ≫ スラスラわかるC# 本書の「はじめに」のところにも書いたんですが、これ、「C# によるプログラミング入門」の改良版です。 まあ、うちのサイトを見てるとお気づきかと思いますが、「予定」とか「書きかけ」とかいう文字がそこいら中にあったりします。その「予定」が本になりました。 サイトの方もいずれは直す「予定」、予定なんですが。とりあえず、当面、うちのサイトは書籍「コンピュータープログラミング入門以前」の内容をサイト内の「コンピューターの基礎知識」に反映させる作業の方が優先だったり。
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ページ: 同期コ
non-nullable reference type
何度かこの話だしてるものの。C# に、参照型だけども null が絶対入っていないことを保証する型（non-nullable）はなぜないの？という話。 それなりにしっかりと説明してるブログ記事を見つけたのでリンク: Difficulties with non-nullable types (part 1) Difficulties with non-nullable types (part 2) Difficulties with non-nullable types (part 3) Difficulties with non-nullable types (part 4) 以下、簡単な日本語解説。 non-nullable？ .NET は元々、値と参照の区別しか持っていなくて、 値型は常に 非 null （non-nullable） 参照型は null を許容（nullable） でし
for Desktop, for Phone, for…?
商標問題で Metro が使えなくなって久しいですが。「My アプリ for Windows Store」も嫌だし、そもそも商標問題なくても「for Metro」も微妙よなぁという話。 Windows Phone 8 の方が Windows 8 とコアの共通化したのでなおのこと。 Metro 改め ちなみにまあ、商標的なところに使わなければ割と平気で、開発者通称的には Metro で通せなくもなさそう（アプリ名とかに使えないことに変わりはないですが）。 商標的なところにおいてどうなったかというと、 Metro アプリ → Windows ストア アプリ Metro デザイン → Microsoft Designe Language でしたっけ。 for Windows Store おい、お前、デスクトップ アプリも Windows ストア上に並べてるくせに（リンクのみ。ストア上からの[イン
非同期処理とディスパッチャー
24日・25日とWDDに行ってたわけですが。 講演者の皆様、UIスレッドとディスパッチャーの話で苦労されてた印象。この辺りの仕組み、どうなんだろうなーとか、少し書いておこうかと。 UIスレッドに紐付いたクラス まず前提。 UIスレッド まず、GUIがらみのクラスは、単一スレッドからしかアクセスできないように作ってあります。スレッド安全に作ろうとするとパフォーマンスが出ないので、いっそのこと、UIスレッド以外からアクセスがあったら例外を出して止まるように作ってあります。 この、GUIコンポーネントと紐付いているスレッドがUIスレッドです。 エンド ユーザーからの入力なんかを受け付けているのもこのUIスレッドで、UIスレッド上で時間がかかる処理をすると、UIがフリーズします。 なので、時間がかかる処理をするときは、一度別スレッドで処理して、結果をUIスレッドに戻すというフローが必要です。 WP
Null非許容
先週、「C#にもNull非許容な型が欲しい」という話をされたものの「うん、欲しいね」としか返せなかったり。要望は昔からあるけども、実際入れようと思うと結構大変。という話、説明しておいた方がいいんだろうなぁと思ったので、ブログにしてみることに。 先に結論の要旨だけ書くと、以下のような感じ。 C#だけで完結する問題じゃなく、.NETレベルで対応するのは今からだときつい Code Contracts使って契約プログラミングするのがいいよ 以下詳細。 公式の見解 Anders Hejlsberg も、「もしもの話」として、1からの再設計が許されるなら C#/.NET をどうしたいかという質問に対して「Null 許容性の見直し」を挙げています。 一時期、結構頻繁にそういっていたと思います。少し検索して出てきたのでいうと、以下の Q&A インタビューの、1:00:00 からのくだり。 今、値型に関して
フリーズしないアプリケーションの作り方
@IT 向けに書いた記事が公開されました。 フリーズしないアプリケーションの作り方 これもまた、裏ではいろいろと思うところあり。 タイミングよかった いやー、題材が題材だけに、C# 5.0 とか .NET Framework 4.5、VS11 の正式版が出る頃に出そうかなーなどと思って書き貯めてあった文章だったり。 諸事情あって、実は意図せず今月完成させて出すことになって、今日の公開だったわけですが、意図せずいいタイミングになったなぁ。 BUILD での発表内容がもうほんと非同期処理だらけで。「WinRT では50ミリ秒以上かかる処理は非同期APIにします」とか、C# 5.0 の async/await 構文の再説明も多々入っていたり。 ついかっとなってやった。後悔なんてあるわけない。 まあ、非同期処理は一応、年々ホットな話題になってきているので、他にも記事はあるにはあります。 ただ、自分
WinRT に関する誤解
まあ、ます先に、ダウンロード リンク一覧を Microsoft Visual Studio 11 Developer Preview (ISO) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=415c1589-a7b1-4b25-93fa-11bb6f29a5be Microsoft Visual Studio 11 Developer Preview (Web インストーラー) http://www.microsoft.com/downloads/ja-jp/details.aspx?FamilyID=99a58e56-fcb2-4264-bce7-3311cf0d1806 Microsoft Visual Studio Team Foundation Server 11 Developer Preview
Windows 8、WinRT « ++C++; // 未確認飛行 C ブログ
BUILD、まだ基調講演くらいしか見れていませんが、それだけでもなかなかに素敵。 そして、公開されて間もないWindows 8の開発者プレビュー、さっそく使ってみているわけですが。 開発者的に気になっていたのは、うわさのWinRT。 コードネームとかじゃなく、正式名称的にもこの名前でよかったわけですが、実物見るとなかなかに楽しそう。 Metroアプリ vs 既存デスクトップ 開発スタイル的には全く別系統でした。いわば、Silverlight と WPF みたいなもの。 Metro アプリ タブレット向け、タッチUI たぶん、ARM版で快適に動かそうと思ったらこっち App Storeで配布できるのはこっちだけ WinRTを使って作る（ネイティブ、.NET、JavaScriptから使える） 感覚的に、一番近いのはWindows Phone 7向けSilverlight（が、.NET 4.5相
BUILD での注目点
BUILD 直前ですね。 ということで、先週あたり、色々と「BUILD での注目キーワード」みたいなまとめ記事が色々出たわけですが。 Windows 8: What we know so far Ten watchwords for Microsoft’s Windows 8 conference Microsoft Build: Developer topics to watch これらを荒く日本語でまとめてみようかと。 （そういや、超前倒しで IS12T が発売されてるものの、本来は Windows Phone 7.5 も BUILD 近辺でリリースのはずよなぁ。） Windows 8: 今までにわかっていること ARM-based チップセットのサポート かなり初期から言われていたわけですが、ARM サポートが入ります。あと、システム オン チップのサポートが入ります。つまるところ、
開発者にとってのWindows 8
Windows 8 上の開発環境について、ようやくきれいに整理された情報が。 Windows 8 for software developers: the Longhorn dream reborn? といっても、公式アナウンスではなくて、リークした Windows 8 （もちろんβにも満たない開発途上版）の解析結果から得られた知見。 少々私見も込みで、要約: .NET がもたらしたもの まず少々歴史の振り返りを。 .NET Framework 登場以前、90年代に置いて Windows 開発がどういう状況だったかというと、「C++ と VB のパリティ（あっちを立てればこっちが立たず的な偶奇性）」という深刻な問題がありました。 Windows の機能を最大限使いたければ Win32 API を使う必要があって、それは VB では難しかった。あと、パフォーマンスの問題もあり、大規模で応答性
WPF の {Binding Path=/}
昨晩、こんな話が： コレ クションをバインドした時に何が起きているか WPFのBindingのPathの解決は結構複雑なことをしております。何のせいでそんなに複雑になるかというと、「マスター詳細シナリオ」とか言う概念のせいだったりします。 マスター詳細シナリオ 以下のページ参照： データ バインディングの概要 （ページ内を「マスター詳細シナリオ」で検索すれば該当箇所に） IsSynchronizedWithCurrentItem プロパティ DataContextに何かコレクションを与えた上で、選択項目の詳細を見たいという場合があります。こういう状況を指して「マスター詳細シナリオ」と呼んでいるようです。 データ バインディングでは、以下のように、Path=/ と書くことで、「コレクションの選択項目を参照しろ」という意味になります。 <ListBox ItemsSource=”{Bindin
INotifyPropertyChanged の実装
追記： 色々更新した 前々から気になってはいたんだけども。 MVVMパターンのViewModelで、INotifyPropertyChangedをいちいち実装すんのかったるい。かといって、AbstractなViewModelBaseは継承したくないでござるよ。 ちょっとイケてるINotifyPropertyChangedの実装 今の C# だと、手書きだけで INotifyPropertyChanged の実装をうまくやろうと頑張るのは厳しいと思うんですよね。コードスニペット使うのを前提に考えるのが一番いい妥協だと思います。 ということで、以下のようなものを作成。 ヘルパークラス（C#） とりあえず同じプロジェクトにぶち込むなりライブラリ化するなり コードスニペット マイドキュメントの下の、Visual Studio のフォルダー以下、Code SnippetsVisual C#My Co
非同期 C# サンプル動画
動画ブログ。 完成品： ソースコード一式（zip 書庫） WPF プロジェクトを作って、AsyncCtpLibrary.dll を参照しただけの状態からスタート。 うちの C# 入門の記事タイトル一覧を取得して、ListBox に表示する簡単なプログラム。 5分弱。 キー入力の履歴表示付き（まだちょっとバグありで、括弧の表示がおかしいけども） 参考： http://ufcpp.net/study/csharp/sp5_async.html http://cid-5c622397e11c979d.office.live.com/view.aspx/ufcpp/misc/GUI%e3%81%a8%e9%9d%9e%e5%90%8c%e6%9c%9f.pptx
ASP.NET MVC 3 プレビュー版、WPF4 トレースオプション、XAML Toolkit CTP、等々
ASP.NET MVC 3 プレビュー版、WPF4 トレースオプション、XAML Toolkit CTP、等々 leave a comment » ASP.NET MVC 3 Preview 1 is released! 気になるのは dynamic な ViewModel とかいう部分。 WPF の DataContext も dynamic 型だった方が使いやすかったかもねぇ（導入時期的な問題で無理だけども）。 Visual Studio 2010 Trace Options for WPF 4.0 WPF はデータバインディングが強力な反面、バインディングで何かミスってても原因追いづらい！って思ってたけども、実は VS 2010 で色々とトレースできるようになってたらしい。 Microsoft XAML Toolkit CTP – July 2010 LINQ フレンドリーにな XA
immutable
変数の immutability に関する議論、今に始まった話でもないんでしょっちゅう見かけるには見かけるんですけど、まとめ的な話はあんまりきれいにまとまってるところ見かけないなぁとか思ったり。 というので、まだそんなにきれいに整理できてるわけでもないけど、ちょっと書いてみる。 値の不変性 値の不変性にもいくつか種類があって、 constant： コンパイル時定数に名前を付けておきたい 扱いが完全にリテラルと一緒になるやつ C# の const C++ の場合、#define の代替としての const ようは、パフォーマンス的な話で、コンパイル時に解決できる値は全部コンパイル時にやっちゃいたいって話 ぶっちゃけ、リテラルが定義できるようなものだけ const 付けれればいいのかなぁと C# の場合、整数型と string と enum だけが const になれる C++ は逆に、con
コードスニペットを使った INotifyPropertyChanged の実装（再度更新）
ソースコード、dll、snippet ファイル詰め合わせ 前回からの更新： プロパティ名、internal static readonly の方がよかった 補助関数とか、dll 化 ついでに MVVM でよく使う DelegateCommand とか、依存プロパティ用のコードスニペットも追加 正直、結構な割合車輪の再発明 以下、サンプル： class Sample : DependencyObject, INotifyPropertyChanged { public int X { get { return (int)GetValue(XProperty); } set { SetValue(XProperty, value); } } public static readonly DependencyProperty XProperty = DependencyPropertyHelpe
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
