サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
Appleイベント
ufcpp.net
レコード型 C# 9.0 で、レコード型(records)という新しい種類の型が追加されました。 record (記録)という名前通り、データの読み書きに使うことを意図した型です。 例えば以下のような書き方で、「Name という文字列と Birthday という日付」を読み書きできます。 using System; record Person(string Name, DateTime birthday); 詳しくは「レコード型」で説明します。 init-only プロパティ 以下のように init という新しいアクセサーを使って、「オブジェクト初期化子までは書き換え可能で、それ以降は書き換えできないプロパティ」を作れるようになりました。 var p = new Point { X = 1, Y = 2 }; p.X = 3; // ダメ。 class Point { public int
また何件かまとめて、C# Language Design Meeting 議事録を紹介。 October 12th, 2020 October 14th, 2020 October 26st, 2020 主に、csharplang の運営方針に関する話と、こまごまとトリアージ話。 (この他に、 October 21st, 2020ではプライマリ コンストラクターの話があったり、 Meeting 議事録とは別に派生型の網羅性の話が出てたりするんですが、 またちょっと話が大きくなりそうなので別の回で改めて。) これの割と冒頭で話してるんですけども、csharplangで、Community Ambassador (コミュニティ大使)を設けようという話が出ていました。 (実際、ほぼ即日、何名か任命。) C# はオープンソース開発されているといっても、マイクロソフトの C# チームが責任を負ってど
いくつかライブ配信では言ってたんですが、C# 9.0 がそろそろ機能確定しそうな感じ。 11月リリースと言ってるわけなので、まあ、時期的にもこの辺りで確定していないとまずいでしょう。 ということで、先日、 What's new in C# 9.0 もドキュメント化されて docs 上に公開されました。 What's new in C# 9.0 見出しに載るようなレベルでの機能の増減はもうありません。 Records とか Function pointers とか、一部の機能はまだちょっと修正が入るかと思います。 それに関しては9月9日の Design Meeting 議事録にまとまっています。 (同日の議題には C# 10.0 の話題というか、C# 10.0 に流れてしまったものの話もあり。) C# Language Design Meeting for September 9th, 20
5日に、Visual Studio 2019 の 16.7 と、16.8 Preview 1 がリリースされました。 Visual Studio 2019 v16.7 and v16.8 Preview 1 Release Today! ということで、先週、ライブ配信もしていました。 16.7 が正式リリースになった記念に、Preview の頃に触れてた話題を改めてちょこっと振り返ったのと、16.8 Preview 1 で新たに追加された C# 9.0 の3つの機能の話でした。 C# 9.0 に今回追加されたのは以下の3つです。 Module Initializers Static anonymous functions Target-Typed Conditional Expression 今日は主にこの3つについて説明。 Module Initializers モジュール(exe (ア
概要 実行可能なプログラムを書くとき、最初に呼び出される処理をエントリー ポイント(entry point: 入場地点、入り口)と言います。 C# の場合、通常、Main という名前の静的メソッドを1個だけ書くことで、このメソッドがエントリー ポイントになります。 また、複数の Main メソッドを書いてそのうちの1つをエントリー ポイントに選ぶ方法があったり、 C# 9.0 からはトップ レベル ステートメントという書き方でエントリー ポイントを作れたりします。 本項ではこの C# のエントリー ポイントに関する仕様について説明します。 C# のエントリー ポイント C# 関連のチュートリアルでのサンプル コードや、 テンプレート通りに C# プログラムを新規作成すると以下のような内容になっていることが多いと思います。 using System; namespace ConsoleApp
先月くらいからじわじわと、C# Language Design Meeting で Records がらみの議題が上がっています。 最近やっとまとまってきた感じがするのでまとめて紹介。 LDM notes for May 4 LDM notes for May 11 LDM Notes for May 27 LDM notes for June 1 record 型の新設 まず、基本方針として、record は class/struct に対する修飾子ではなくて、enum とか delegate とかと同じく1種の型みたいな扱いにしたみたいです。 なので、以下のような書き方に。 record Point(int X, int Y); とりあえず初期実装としては結構やることを絞るみたいで、 record は参照型 値型なものは既存の struct に手を入れるか、"record struct
ここ1週間くらいで、C# 9.0 で入るであろう機能がちゃんとした仕様ドキュメントに起こされ始めました。 Add draft spec for C# pattern-matching changes. #3361 Add proposal for target-typed conditional expression. #3363 C# Language Design for April 13, 2020 (Roadmap for records) Init only proposal document #3367 パターン マッチング v3 パターン マッチングも3世代目になります。 最初 C# 7.0 に入ったころは単に「is がちょっと便利になった」、 「switch で型分岐ができるようになった」程度の機能でしたが、 3世代目ともなるとずいぶんいろいろなものが増えています。 詳細は
数日前、いくつかの新機能について、仕様書のドラフト案が上がっていました。 base(T) - Draft Specification #2910 UTF8 String Literals - Draft Specification #2911 どちらも、これまであった Design Meeting の議事録通りな感じ。 あと、ちょこっと変更が検討されて、結局元さやに納まったものが1件。 Champion "Lambda discard parameters" #111 base(T) - Draft Specification #2910 これは、C# によるプログラミング入門に説明を書いた直後に「やっぱり C# 8.0 ではやめておく」となってしまったやつ。 (しょうがないんで「C# 8.0 から外れました」って書き足してそのまま残してあったり。) まあ、.NET ランタイムのレベルで対
corefx で以下のようなアナウンスが。 .NET Core 3.0 concludes the .NET Framework API porting project buildの時点で .NET を .NET Core ベースに一本化、.NET Framework は 4.8 をもって最後にするという話があったわけですが、 改めてというか、総括的なアナウンスです。 API 数 まず、.NET Framework から .NET Core に移植してきた API 数の総括。 メソッドのオーバーロード1個1個を「1 API」とカウントしてるんだともいますが、以下のような数字が書かれています。 .NET Core 1.0 時点では1.8万個 .NET Standard 2.0 では .NET Framework、.NET Core、Xamarin の共通部分として3.8万個 Windows
(日本時間だと)昨晩深夜、.NET Conf 2019がありましたね。 キーノートはなんかgRPC一色だった感じが… 要は、ASP.NET Core 3.0 の目玉の1つが gRPC 対応なんですけども。 それを、 proto ファイルから ASP.NET のサーバーを作るデモ 同じ proto ファイルからクライアントコードを生成するデモ WinForms とか WPF が .NET Core で使えるようになった → WinForms のデモでも生成した gRPC クライアントを利用 Xamarin にも、hot リロード、hot デプロイ機能が入る(プレビュー) → Xamarin のデモでも同じ gRPC クライアントを利用 Blazor のデモでも同じ gRPC 生成した gRPC クライアントは C# 8.0 対応 → await foreach のデモに利用 という感じ。 ち
概要 Ver. 8.0 C# くらいの世代(1990年代後半~2000年代前半)のプログラミング言語では、 参照型には null が「つきもの」で、不可避なものでした。 (参考: 「null参照問題」。) ただ、2010年代ともなると、「つきもの」として惰性で null を認めるのはよくないとされています。 C# でも、少なくとも「意図して null を使っているかどうか」を区別できる必要性が生まれました。 そこで C# 8.0 では、以下のような機能を提供することにしました。 参照型でも単に型 T と書くと null を認めない型になる T? と書くと null を代入できる型になる C# 7.X の頃と 8.0 で何が変わったかというと、 「参照型でも null を拒否できるようになった」ということになります。 ただ、「T? と書いたときに null 許容」という方式なのと、値型との対
一昨日、Visual Studio 2019 16.2 の Generally Available と 16.3 の Preview 1 が出ました。 あと、.NET Core 3.0 Preview 7 も出ました。 Visual Studio 2019 version 16.2 Generally Available and 16.3 Preview 1 Announcing .NET Core 3.0 Preview 7 16.2 の機能: テスト エクスプローラーの UI が見やすくなった 16.3 Preview 1 の機能: 起動画面でのプロジェクト検索や、プロジェクト テンプレートの検索がしやすくなった .NET Core 3.0 や C# 8.0 のサポート追加 LangVersion を 8.0 や preview にしなくても C# 8.0 が有効 .NET Core
昔、gist にだけ置いてて、そういえばブログに書いてなかったものを思い出したので書いておくことに。 (一応、部分的には言及したことがあるんですけど、ちゃんとした話はしたことがなかったはず。) 決定論的ビルド 3年くらい前まで、C# コードをコンパイルすると、ソースコードを一切書き換えていなくても、生成結果の exe/dll や pdb のバイナリが変化していました(決定性(deteminism)がない)。 原因は以下の2つです。 バイナリ中に埋め込まれる GUID にタイムスタンプと乱数から生成される値を使っていた デバッグ用のファイル情報がフルパスで埋め込まれていた GUID の方はタイムスタンプと乱数なので本当に致命的で、ローカルで再コンパイルしても毎回バイナリが変化していました。 フルパスの方は基本的には pdb (デバッグ用シンボル情報)だけの問題なんですが、 exe/dll で
今年の build、思ってたよりも .NET がらみが盛沢山… Windows TerminalとかVisual Studio Onlineとかの方がさらにインパクト強そう? ですけど、 .NET がらみもだいぶ。 まあ、3.0 が今年こそ見えてきましたからね。 Introducing .NET 5 .NET Core 4 は Framework 4.X と紛らわしいから欠番にして、次は「5」 徐々に .NET Core に一本化して、名前も「.NET」に .NET Framework は 4.8 を最後のバージョンにすると明言 Mono の機能は徐々に取り込むとのこと 最初の目標は corefx(ライブラリ部分)をcoreclrと Mono VM で99%共有化とかからと言ってるので先は長そう これからは年に1回、毎年11月にメジャー リリースする 2019/9 に .NET Core
C# 8.0 にはいろいろな新機能が含まれていますが、 主要なものは堅牢性向上を目的としたものになります。 プログラマーの人的ミスを避け、より堅牢なプログラムを書けるようにしたいというものです。 補足 バージョン指定 ちなみに、C# 8.0 世代の C# コンパイラーから、バージョンの指定方法に preview というオプションが追加されました。 このオプションを指定することで、正式リリース前の機能をある程度先取りして試してみることができます。 例えば、C# 8.0 がデフォルトで有効になるのは Visual Studio 2019 16.3 からですが、 preview 指定であれば 16.0 の頃から使えました。 (名前通りプレビュー状態なので、正式リリースまでに変更が掛かる可能性が高いので注意は必要です。) ターゲット フレームワーク C# 8.0 の全ての機能を一切の小細工なしで満
サンプル コード: https://github.com/ufcpp/UfcppSample/tree/master/Chapters/Data/Patterns 非再帰パターン Ver. 7.0 C# の文法上の区別する意味はないんですが、 パターンのうち、C# 7.0 で入ったものと 8.0 で入ったものの一番の差は再帰があるかどうかです。 C# 7.0 からあるパターンは1層限り、8.0 で追加されたパターンは再帰的に何層もマッチできます。 (再帰がある方が難しいので後からの追加になりました。) ここではまず、文法が簡単な再帰のないパターンから説明していきます。 型パターン (宣言パターン) C# 6.0以前から元々あった is 演算子の自然な拡張になっているのが型パターン(type pattern)です。 以下のように、型の後ろに続けて、マッチした結果を変数で受け取れます。 sta
これまで(C# 7.3 まで)、C# の switch ステートメントで bool 型を使う場合、以下のように、default 句が必須になることが多々ありました。 static int X(bool b) { switch (b) { case false: return 0; case true: return 1; default: return -1; } } bool 型には false と true しかないはずなのにこれはおかしいと言われ続けていたんですが、C# 8.0 では default 句が要らなくなるというか、default 句を絶対に通らなくなるよう、コード生成の仕方を変更するみたいです。 今日はこの辺りの、要するに「false でも true でもない bool 値」の話。 サンプルコード: BoolExhaustiveness bool とは ドキュメント上 ま
C# では、無効な値として null をよく使うので、 「値が有効かどうか」「無効だったら何もしない」みたいな判定のために null チェックを結構書きます。 で、C# の null は「全ビットが0」で表されるので、通常、null チェックは非常に軽い処理(単なる 0 との比較)になります。 通常は。 問題は、== 演算子のオーバーロードがある場合。 その場合、x == null は、演算子(を表すメソッド)の呼び出しになります。 もしその == 演算子がインライン展開できないものだった場合、「単なる0比較」と比べると大幅に遅いコードになります。 なので元々、== 演算子のオーバーロードがある場合には、x == null ではなくて、 (object)x == null や、ReferenceEquals(x, null) を使えという話もあったりします。 ですが、これらはちょっと長った
今日は、おそらく .NET Core 3.0 で正式リリースとなるであろう最適化の話。 Hardware Intrinsics といって、特定 CPU の専用命令を利用するための機能の話になります。 元々は .NET Core 2.1 の頃に作業が始まっているんですが、2.1 リリースのタイミングには間に合いませんでした。 しかし、内部的な対応はすでに入っていて、daily ビルドなパッケージを参照すれば、今現在の .NET Core 2.1 でも利用可能です。 というか、ドキュメントはすでにあります。 CPU 専用命令 いろいろなプログラミング言語で書かれたプログラムを比較したとき、 傾向として言うと、C 言語や C++ で書かれたものが最速です。 C# は、これら C や C++ と比較してどこがボトルネックでしょう。 印象としてはガベージ コレクションが遅そうに思われるかもしれません
今日はまたちょっと将来の話。 リリース時期・本当にリリースされるか未定の機能で、メモリ管理がらみの話をまとめて。 ヒープ確保の負担を減らしたい メモリの管理方法にはスタックとヒープがあって、 一般的にはスタックの方が高速です。 スタックの方が制限がきついので、遅くてもしょうがなくヒープを使う場面がでてきます。 ヒープ管理は結構大きな負担なので、これを減らせば結構なパフォーマンス改善になります。 いくつか方向性があって、以下のような最適化が考えられます。 ヒープ管理自体を賢くする → ガベージ コレクション → Arena Allocation (後述) ヒープを避ける 手作業でヒープを避ける C# が構造体とかの「値型」を持っているのはこのため → 先日書いた「Span<T> 利用による最適化」とかもまさにこれ 自動でヒープを避ける → Object Stack Allocation (後
なんか、昔作ったGraphemeSplitterがC++方面のUnicodeがらみのブログから参照されてたので、ちょっと補足。 UNICODE TEXT SEGMENTATION 「書記素って何?」って話は詳しくは昔書いた記事でも見てもらうとして。 とりあえず、「人間が見て1文字と思うようなもの」を指して書記素(grapheme)といいます。複数の Unicode コードポイントが結合しまくるので、可変長。 いつも例に出すのが家族絵文字(👩🏻👦🏼👨🏽👦🏾👦🏿👩🏼👨🏽👦🏼👧🏽👩🏻👩🏿👧🏼👧🏾とか)ですが、1書記素で11コードポイント、UTF-8で41バイトになったりします。 で、問題は、書記素の機械的な判定方法。 コンピューター上でもちゃんと書記素単位で処理してくれないと、人間の感覚からすると「backspace/dele
今日も C# 8.0 の新機能の話。 C# 8.0 の中でおそらく一番の目玉機能扱いになると思われる null許容参照型の話です。 参照型でもそのままでは null を認めない 要は、参照型に対しても、単にTと書くとnullを認めない型になり、 null許容にしたければT?と書くようにするという機能です。 #nullable enable // string には null が来ない // null が来ないなら s.Length で OK static int M1(string s) => s.Length; // string? には null が来る // null が来るのに s.Length (null チェックしてない)はダメ static int M2(string? s) => s.Length; // string? には null が来る // null が来ても ?
今日もC# 8.0の新機能の話で、今日のはすでに Visual Studio 2019 Preview 1に入っているやつです。 Ranges and Indicesと呼ばれていて、配列などに対して、 a[^i]で「後ろからi番目」とか、 a[i..j]で「i番目からj番目の範囲」とかを取り出せるようにする機能です。 正確にいうと、^iとかi..jとかの部分がC#の新機能で、 これらはそれぞれIndex型、Range型になります。 Index、Rangeを受け取るインデクサーやメソッドはライブラリ側の機能です。 (ただし、配列だけは言語レベルで処理している模様。) 背景1: 統一ルールが欲しい 一旦先ほどの説明は忘れてまっさらな状態で、 例えば「3..5」と言われると何を思い浮かべるでしょう。 文脈次第だとは思いますが、以下のようなものがあり得ます。 3, 4, 5 (5も含む) 3, 4
Visual Studio 2019 Preview 1 が出て、 さすがに C# 8.0 に入る機能・入らない機能がある程度見えてきたので、 今日からしばらくその辺りの紹介をしていこうかと。 とりあえず今日は、「1記事使うほどでもないような小さい奴」をまとめて紹介。 文字列補完、$ と @ の順序緩和 ??= (null 合体代入)演算子 構造体の宣言時、refとpartialの順序緩和 分解の右辺に default 式 入れ子の{}内での stackalloc unmanaged 制約付きの型引数に、ジェネリックな型を渡す ちなみに、VS 2019 Preview 1 で実装されているのは上の2つだけです。 順序緩和 C# のキーワードには、並び順を自由に変えられるものがいくつかあります。 代表的なのはクラスやメソッドに対する修飾子ですが、例えば以下の3行は全く同じ意味になります。 s
Connect やってましたね。 とりあえず、関連ブログ: Making every developer more productive with Visual Studio 2019 Visual Studio 2019 Preview Announcing .NET Core 2.2 .NET Core 2.2 downloads Announcing .NET Core 3 Preview 1 and Open Sourcing Windows Desktop Frameworks Announcing Open Source of WPF, Windows Forms, and WinUI at Microsoft Connect(); 2018 Announcing WPF, WinForms, and WinUI are going Open Source .NET Core
なんか、Gist に書き捨ててそのまま放置なものが結構増えてきたので、 しばらくそれを元にブログに起こしていこうかという気分に。 ここ2年くらい、.NET Core や C# のテーマの1つがパフォーマンス改善だったせいもあって、だいぶ Unsafe でだいぶきわどい最適化の話が多めになるとは思います… (ちなみに、今日のは全然その系統ではなく、きわどさもない話。) Visual Studio 2017 の頃から、所定のフォルダー以下にあるすべての csproj に対して掛かる共通設定を記述できるようになりました。以下の名前のファイルを置くことで、その内容が自動的にcsprojにインポートされます。 (dotnetコマンドでのビルドにも有効です。) Directory.Build.props … csprojの先頭にインポートされる Directory.Build.targets … cs
一昨日、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 に対応しない」みたいな感じのことが話題になっていますが。 これ、多少不正確
一昨日のあれ、まだなんかやってんだ… なんか、個人的にはこういうのはもっと機械的に処理されてほしく、 言うこと言ったあとは、 なんか2chみたいな荒れ方し始めたから unsubscribe してたんですけども。 機械的に処理してるのが、冷たくあしらったり避難してるように見えてたら嫌だなぁということで、 ちょっとエモい感じの補足を。 最初の1行コメントについて 最初の1行コメント あー、これはひどい誤訳だわー。よくあるけど。 それじゃたぶん通じてないけど、ご報告ありがとうございます。あとはこっちで処理しておきます。 というつもりだったんだけど、「それじゃ通じない」のところだけを取られて、避難してるみたいに見えたみたいで、そこは本当に申し訳ない… 誤解の原因になったやつについて 誤解の原因になったやつ これが誤解の原因になってるなぁ… まあ、わかりみが深いけども。マイクロソフトのドキュメントに
だいぶ炎上してる例のあれ doの意味が全体的に逆になっています。 #118 対応ミスってるとはいえさすがにかわいそうなレベルでいいがかり付けられてる感じもするのでちょっと補足を。 元々の問題 マイクロソフトの機械翻訳がよくやらかすのはいつものことなんですが。 今回は何をやらかしたかというと、よくある ✓DO: 〇〇してください X DO NOT: 〇〇はしないでください みたいなやつを、DOもDO NOTもどっちも「しないで」と訳してしまっているという問題。 「しないで」も不自然だし、ましてDOの方は真逆の意味になっているという誤訳。 どうしてこうなる… みたいな気持ちはもちろんあるものの、こういう「普通の文章」になっていない部分の単語ってのは、機械翻訳では一番ミスを起こしがちな部分です。 たぶん、原文の時点で何らかのアノテーションでも付けておくとかしないと、今後も同様の誤訳は起こりまくる
次のページ
このページを最初にブックマークしてみませんか?
『++C++; //未確認飛行 C++』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く