タグ

ブックマーク / ufcpp.wordpress.com (16)

  • C# 7に向けて(2): 性能と信頼性

    C# 7の提案のうちいくつかを見た瞬間、思ったのは「C++ 11みたい」でした。 まあ、背景には、年々C#の適用範囲が広がっていること、そして、オープンソース化に伴って今後はさらに広がるであろうことがあります。 ゲーム開発の標準言語と言えばC# その広がった先の1つはゲーム開発でしょう。「ゲーム開発の標準言語と言えばC#」なんていう煽り(わりかしほんとに「煽り」ではあると思う。「話題にならないよりは炎上する方がマシ」くらいの覚悟の上の)もあります。まあ、割かし昔から、ゲーム開発者にもC#好きな人はいて、ゲーム会社の社内ツールなんかはC#で書かれることが結構あったみたいです。しかし、「ゲーム自体を」となると、これは割かし最近の話。「XNAがあったし(震え声)」と小声で主張もしたいところですが、実際のところ、割かし皮肉なことに、「C#でゲーム開発」が注目を浴びるようになったのはUnityのおか

    C# 7に向けて(2): 性能と信頼性
  • 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に向けて(1): 変数やフィールドの書き換え
    raimon49
    raimon49 2015/02/01
    immutableキーワードによるdeppなimmutability constやreadonlyとは違って階層的に不変であることが保証される
  • 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#の言語バージョンと.NET Frameworkバージョン

    ※1 … 書き方によっては4.6でないと動かなくなる ※2 … 拡張メソッドの制限そのまま。拡張メソッドを2.0で動かす方法はあるので、それを使えば2.0 ※3 … 同様に、await演算子の制限。4で動かすすべあり 動かし方、補足など 前節の表で、2.0で動くとなっているものは、要は、ライブラリ依存がなくて、単純にC#コンパイラーだけの仕事で実現できる機能です。 逆に、特定のバージョンに依存しているものは、そのバージョンで追加されたクラスに依存しています。 なのに、古いバージョンの.NET Frameworkでも「動かすすべがある」というのはどういうことかというと、あるクラスに依存するといっても厳密なチェックをしているわけではなく、同じ名前・同じ機能のクラスを自前で実装すれば動きます。なので、原理的に言うと、どの機能でも.NET Framework 2.0で動かせるんですが… C#機能ご

    C#の言語バージョンと.NET Frameworkバージョン
    raimon49
    raimon49 2015/01/01
    コンパイラ依存かライブラリ依存かの話。
  • 実行コンテキスト

    久々に、そのうち http://ufcpp.net/study/csharp/ に載せる前提の下書き的なブログ。 概要 .NET Frameworkのスレッドは、実行コンテキスト(execution context: 実行の文脈)というものを持っています。 「文脈」という言葉の意味するところは、「意識することなく皆が共有している情報」ということです。実行コンテキストの場合は、以下のような情報を、スレッドを超えて共有します。 セキュリティ コンテキスト: どういう権限でそのスレッドが動いているかを伝搬して、適切なセキュリティを保つ 論理呼び出しコンテキスト: (実際の呼び出しスタック上の上下関係でな く、)論理的な呼び出し関係での情報共有 情報の共有範囲 実行コンテキストを理解するためには、まず、どういう範囲で情報を共有できればいいのかという話をしましょう。 静的フィールド オブジェクトをま

    実行コンテキスト
  • C#、2012年の首位プログラミング言語に名が挙がる

    C# Named Top Programming Language of 2012 Eight Reasons C# is the Best Language for Mobile Development 集計方法1つ変えるだけで順位なんて変わるという話でもあったりはするのだけども。 ある指標では、2012年で一番伸びた言語はC#ということになるそうです。 去年、C#とか.NET周りで何があったかというと、MonoTouch/Mono for Android であったり、Unity(Monoベースのゲーム エンジンの)であったり、Windows 8であったり。 Windows 8 Windows 8、というか、WinRTで、ネイティブ(C++)の復権があったり、JavaScript+HTML5での開発もできたりで、世の中には「.NETは下火」なんていう人もいるにはいましたが。実際にWind

    C#、2012年の首位プログラミング言語に名が挙がる
  • 大切な事は全て.NETから学んだ

    下記の文章、「こういうテーマでufcpp.net内のC#ページを更新(今の【雑記】的にやるか、新しいフォルダー掘るかして)したい」というもの。 いつ手を付けるかは未定。実際のところしばらく無理。 表題、誇張ではなく、割と真実。 ソフトウェアに求められる品質水準は非常に高くなっていて、開発者に求められる知識は年々増えています。 単純にプログラミング言語の基礎を覚えるというだけではまるっきり不足で、そこから様々なパターンを覚えて初めて実用化に足る最低水準になります。 パターン。 こういう場面ではこう書くと解かりやすい こう書かないとこんな問題が 計算速度優先ならこう、省メモリならこう 等々、いわゆる先人の知恵。 歴史を積み重ね、普通に1からたどるにはあまりにも遠い道のりに至りました。 先人と同じ手順を経ていては、追いつくことで精一杯。その先の新しい世界を目指すことも叶いません。 楽をするひつよ

    大切な事は全て.NETから学んだ
    raimon49
    raimon49 2012/10/23
    教科書的な言語
  • TypeScript

    マイクロソフトも better JavaScript、かつ、JavaScript に変換して使う言語を作ってきたようで。 日語ニュース記事: MicrosoftJavaScript系の新言語、TypeScriptのデベロッパー・プレビュー版を発表 公式サイト: http://www.typescriptlang.org/ MSDN ブログでの告知: TypeScript: JavaScript Development at Application Scale Miguel de Icaza(GNOMEとかMonoの創始者)の感想: TypeScript: First Impressions 「JavaScript を、最小限の変更で、ツール連携(静的チェックやコード補完)しやすくする」という観点でみて、結構よくできてる。 少し前に、Anders Hejlsberg が JavaScri

    TypeScript
    raimon49
    raimon49 2012/10/02
    スーパーセットかつ最小セット ECMAScript 6.0の標準化をせかす
  • どうしてこうなった

    ほんと、どうしてこうなったかなぁ。 Oralceの対Google訴訟、プログラミングの将来を危うくしている 二分された世界 JVM と .NET、もろに競合なわけですが。少しレイヤーが違うとか、棲み分けできるポイントがあるならともかく、ほんとに2個あってもしょうがない状態。競争があるのはいいと思うものの、どうせ競争するなら最低ラインの仕様そろった中で性能改善とかで競って欲しく。 でも、後発の .NET だけが悪いわけでもないのは今の DalvikVM の状況を見ての通り(Oracle になってひどくなったわけでもなく、Sun の時代も大概)。このままだと仕様が違う第3の仮想マシン(VM)ができてしまってもおかしくない状況… 個人的な意見として、「もしもの話」で、一番よかっただろう道筋は、2000年前後の訴訟がなくて、Microsoft Java VM が生きている状態。.NET が生まれる

    どうしてこうなった
  • Windows 8時代のGUI開発/Windows 8時代の.NET

    金曜日に、@ITで以下のような記事が公開されました。 特集:XAMLファミリ共通開発のすゝめ(前編) Windows 8時代のGUI開発を考える そして、Silverlightを囲む会で以下のような発表をしてきました。 https://r.office.microsoft.com/r/rlidPowerPointEmbed?p1=1&p2=1&p3=SD5C622397E11C979D!3402&p4=&ak=!AFg49XomaSVgLM4&kip=1&authkey=!AFg49XomaSVgLM4 https://skydrive.live.com/#!/view.aspx?cid=5C622397E11C979D&resid=5C622397E11C979D%213402 1万字程度の原稿に加えて、25分間のプレゼン発表って、何この学術発表スタイル。 公約数 VS プラットフォーム

    Windows 8時代のGUI開発/Windows 8時代の.NET
    raimon49
    raimon49 2012/01/01
    PCL: Portable Class LibraryでGUIが分離された経緯。
  • 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

    WinRT に関する誤解
  • 開発者にとっての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 では難しかった。あと、パフォーマンスの問題もあり、大規模で応答性

    開発者にとってのWindows 8
    raimon49
    raimon49 2011/08/27
    >昨今の Web 標準 vs プラットフォーム固有 の対立(HTML5 vs { Java on Android, Objective-C on iOS, Silverlight })の構図、かつての VB vs C++ と同じに見えてしょうがないんですよね。
  • 読み取り専用

    OOP言語でクラスを作る際に重要な点: ユーザーには必要最小限の権限しか与えない 書き換えが不要なら、読み取り専用に作る 自分で書くか、少なくとも設計段階から関わってる分には別に何も困ることなくやれるんでいいんですが、最近、途中入りのプロジェクトで多少苦労していたり。 例えば、「読み取り専用に作れ」って言われたとき、以下のような書き方が考えられます。 (説明に不要な部分は省略) using System.Collections.Generic; class ReadOnlyClass { // (クラス外部から)読み取り専用プロパティ public int X { get; private set; } // (クラス内部からも)読み取り専用プロパティ public int Y { get { return _y; } } private readonly int _y; // これで読み

    読み取り専用
    raimon49
    raimon49 2011/08/27
    「ユーザーには必要最小限の権限しか与えない 」「書き換えが不要なら、読み取り専用に作る 」 IEnumerable
  • プログラミング言語の簡単さ/むずかしさ

    Scala をディスると PV が増えると聞いて。Scala、難しいよね(棒読み)。 そういう冗談さておき。プログラミング言語が簡単/難しいって何だろう。 How vs. What C# もよく言われるんですよね、「C# は簡単だ」というのも、「C# は難しい」というのも両方。で、よくよく話を聞いてみると、だいたい以下のような感じ: C# は文法が多い。概念覚えるのが大変だから難しい。 C# はやりたいことをやれるから簡単。 文法の簡単さ 「プログラミング言語マスター = 文法を覚える」だというなら LISP でも使ってなさいってば。あの言語、超簡単ですよ。() の中にトークン並べるっての以外に何も文法持ってないから。 こういう意見って、要するに、How(どう書くか)ベースの簡単さなんですよね。 やりたいことをやる簡単さ プログラミングって手段であっても目的ではないわけで。What(何をし

    プログラミング言語の簡単さ/むずかしさ
    raimon49
    raimon49 2011/06/13
    >「書くのが楽だから」とか「クラスって概念を教えなくてもいいから」って理由で、標準ライブラリをグローバル関数だらけにしてしまうと、検索性で非常に困ることになる / PHPさん…。
  • 構造体とクラス

    こういった話が。→ Design Guidelines– Classes vs. Structures C# で、構造体とクラスの使い分けはどうするの?ということで、以下のような記述が。 Consider defining a structure instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects. Do not define a structure unless the type has all of the following characteristics: It logically represents a single value, similar to primitive types (in

    構造体とクラス
    raimon49
    raimon49 2010/12/19
    single value, 16バイト以下, immutable
  • 標準と革新

    なんか Silverlight に関していろいろ言われているようなので。 発端となる記事: マイクロソフトが戦略変更。HTML5が唯一のクロスプラットフォーム、SilverlightはWindows Phone 7のプラットフォームに Microsoft は Silverlight をあきらめ HTML 5 へと走る (少なくとも、後者(英語の原文の時点で)はタイトルがよくない・・・) これの意味するところは: 「標準ベース」で、ほんとに iPhone, Android 含め、単一のコードでクロスプラットフォームを目指すなら HTML5 を使ってほしい 当面、Silverlight は Windows Phone 7 に注力 PC 版は「すでにある」ものなので、立ち位置としては、MS 製品内のクロスプラットフォーム 結局のところ、iPhone でいうところの Obj-C、Android

    標準と革新
    raimon49
    raimon49 2010/12/10
    >標準っていうのは、「10年遅れくらいで、かつ、互換性に悩まされる(標準化漏れや対応遅れのバグフィックスまで含めれば10年どころではなく遅れる)のを覚悟の上でも、少しでも間口を広げたければどうぞ使ってくだ
  • 1