What's the role of Go in a universe where Rust exists? Imagine you’re a developer who mainly works with Go. You go to an event and, while chatting with some people, you decide to share with them the news that you wrote a small tool that does something. You claim that since you wrote it in Go, it’s fairly fast, it’s a single binary, etc. The group seems pleased with your recount and you start feeli
Updated post: fixed mike’s twitter handle, replaced example of traffic system with example of path tracer A lot has been [said] (https://youtu.be/rX0ItVEVjHc) and [written] (https://aras-p.info/blog/2018/12/28/Modern-C-Lamentations/) lately about the game industry’s “C++ is not changing into the thing we need” feelings. Valid criticism on various things that make C++ not a great language for games
【Unite 2017 Tokyo】「黒騎士と白の魔王」にみるC#で統一したサーバー/クライアント開発と現実的なUniRx使いこなし術
Unityでasync/await使えてハッピー。が、しかしまだ大々的に使われだしてはいないようです。理由の一つとして、Unityが標準でサポートする気が全くなさそう。少なくとも、Unityがフレームワークとしてasync/awaitには何一つ対応していない。async/awaitという道具立てだけじゃあ何もできないのです、フレームワークとして何らかのサポートがなければ機能しないわけですが、なんと、何もない……。 何もないことの理由はわからないでもないです。パフォーマンス面で不満/不安もありそうですし、マルチスレッドはC# Job System使ってくれというのは理にかなっている(私もそちらが良いと思います、つまりTaskのマルチスレッドな機能は原則使わない)。とはいえ、async/awaitは便利なので、このまま、便利だけど性能は微妙だから控えようみたいな扱い(あ、それ知ってる、LINQ
講演者:河合 宜文(株式会社グラニ) こんな人におすすめ ・C#大統一理論について興味のある方 ・UniRxを使ったことがある/使ってみたい方 受講者が得られる知見 ・C#で統一したプロジェクトの作り方 ・UniRxの活用法、メリットとデメリット 講演動画:https://youtu.be/Lvbs22iZFPk
この記事はUnity Advent Calendar 2014のための記事になります。昨日はkomiyakさんのUnity を使いはじめたばかりの頃の自分に伝えたい、Unity の基本 【2014年版】でした。いやー、これはまとまってて嬉しい情報です。ところでカレンダー的には穴開けちゃってます(遅刻遅延!)、すみません……。 さて、今回の内容ですが、私の作っているUniRxというReactive Programming(バズワード of 2014!)のためのライブラリを、最近ありがたいことに結構使ってみたーという声を聞くので、Rxの世界とUnityの世界を繋ぐ根幹である、MainThreadDispatcherと、その前準備に必要なコルーチンについて書きます。 Coroutine Revisited コルーチンとはなんぞや。なんて今更ですって!はい。とりあえず、Unityは基本的にシングル
と、いうものを作りました。MessagePackのC#版です。以前に作ったZeroFormatterのコードをベースに、バイナリの読み書きをMsgPackのフォーマットに差し替えたものになります。MsgPackのライブラリはすでにあるじゃん(MsgPack-Cli)!ってことなんですが、パフォーマンスにかなり差があります。 neuecc/MessagePack-CSharp JSON.NET(スタンダードで、豊富なAPIを持ってる)に対するJil(スピード特化、APIは必要十分はあるけれどJSON.NETほどではない)のようなものと思ってください。とはいえ、生のまま使っても問題は出ない(デフォルトのままで最高速が出るようにチューニングしてある)でしょうし、カスタマイズの口自体も十分用意してあります!詳しくは「拡張」の項で説明しますが、既に私自身が他のライブラリへの対応・インメモリデータベー
.NETのリフレクションが遅い のは周知の事実ですが、なぜなのでしょうか。この投稿では、リフレクションの 実装 を見ながらなぜ遅いのかを解明します。 CRL型システム設計目標 リフレクションが速くない理由の1つとして、そもそも 高いパフォーマンス が設計上の目標にされてはいないことを挙げることができます。 型システム概要 – 設計の目標および非目標 では次のように記載されています。 目標 コード(リフレクションではない)の実行時に必要となる情報へのアクセスが高速なこと。 コード生成のためにコンパイル時に必要となる情報へのアクセスが容易であること。 ガベージコレクタ/スタックウォーカが必要な情報へアクセスする時に、ロックを解除したりメモリを割り当てたりしなくてよいこと。 一度にロードされる型の数が最小限であること。 指定された型をロードする時、ロードする数が最小限であること。 型システムのデ
C#で、「他の言語との差というと」とか「他の言語から来たばかりの人が書きがちなコード」みたいなことを聞かれた場合、まず何が思い浮かぶでしょう。 C#に馴れちゃってる人だと、LINQとかasync/awaitとかの機能が最初に浮かんだりします。でも、この辺りは「大きな機能」過ぎて、知ってるか知らないかの二択、1度知れば検索してすぐに解説が出てくる類で、かえって問題にならないという印象。 案外、困るのはもうちょっと細かい部分じゃないかと思います。 みたいなのが今日の話題。 辞書(ハッシュテーブル)の列挙 Dictionary<TKey, TValue>の列挙を、キーも値も両方使うのに、Keysを使ってやろうとする人が結構いるらしいという話を聞きます。要するに以下のような書き方。 using System; using System.Collections.Generic; class Prog
7/12 (火) の早朝、長らく検討/開発されてきた待望の Deconstructions (= 型分解) が Roslyn の master ブランチにマージされました!(型分解というのは僕のテキトーな訳で、正式名称は未定) タプル構文が複数の値をひとつにまとめる機能だったのに対し、Deconstructions はその逆の複数の値への分解をサポートします。C# 7 への搭載の期待もさることながら、直近では Visual Studio 15 Preview 4 にも含まれるのではないかと思われます。タプル構文については以下を参照ください。 基本的な記法 まず、System.ValueTuple を分解しつつ基本の書き方を見ていきましょう。以下のような 3 種類の書き方があります。(もっとあったらゴメンナサイ... //--- こんなタプル型のインスタンスがあったとする var t = (
今回は ref 戻り値 (Ref Returns) と ref ローカル変数 (Ref Locals) について見ていきます。それぞれの機能は端的に言うと以下のようなものです。 名称 機能 Ref Returns メソッドの戻り値を参照として返す Ref Locals 値を参照として受ける C++ に嗜みがある方であれば & キーワード による参照渡しと言うと分かりやすいかもしれません。むしろ C++er からすれば圧倒的なイマサラ感すら沸き上がるかもしれません...。この機能は GitHub 上の以下の issues で提案/議論されています。 パフォーマンスの向上 基本的に値型でですが、引数に渡したり戻り値として値を返す場合はメモリ領域が再確保され、そこにコピーが生成されます。以下のような超シンプルなコードでも、実は値が 3 回コピーされています。(確かそのはず... static v
コードを書いていると、稀に関数の中に「そこでしか使わない関数」を作りたくなる場合があります。例えば再帰処理などはその最たるものかと思います。C# 6.0 まではデリゲートを駆使して以下のように書いていました。 static void Main() { //--- 再帰処理したい場合は一旦変数を切る //--- 変数をキャプチャするためのテクニック Func<int, int> fibonacci = null; fibonacci = x => { if (x <= 1) return x; return fibonacci(x - 1) + fibonacci(x - 2); } var result = fibonacci(7); } 書けますし問題なく動作しますが、いちいちデリゲートのインスタンスを作らなければなりません。呼び出し以外のコスト (= インスタンス生成コスト) がかかっ
public const string Foo = "ふー"; public void DoSomething() { // ビルド後は呼び出し元にビルド時の値が埋め込まれる // アセンブリを跨ぐ場合、リビルドするまで呼び出し元は古い値のままになる Console.WriteLine("ふー"); } そもそも文字通り定数でないものは const で公開するべきではないです。 static readonly で公開するか読み取り専用プロパティにします。 また、private および internal メンバーであればアセンブリを跨がないため問題ないです。 インターフェースにメンバーを追加する 言わずと知れたアンチパターン。 言うまでもなく既にそのインターフェースを実装している型があれば死にます。
Instantly test any C#/F#/VB snippet or program Query databases in LINQ (or SQL) — SQL/Azure, Oracle, SQLite, Postgres & MySQL Enjoy rich output formatting, autocompletion with AI and integrated debugging Script and automate in your favorite .NET language Interoperate with xUnit, BenchmarkDotNet, Rx, MSAL, Excel and more Super lightweight — small and fast, with xcopy option Standard edition free wi
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く