変更ログ 2.098.0

テンプレート内のエイリアス宣言に新しい値を割り当てる機能が追加された。 新しい値を割り当てる機能が追加された。例えば、再帰テンプレートである:

template staticMap(alias F, T...)
{
    static if (T.length == 0)
        alias staticMap = AliasSym!();
    else
        alias staticMap = AliasSym!(F!(T[0]), staticMap!(T[0 .. T.length]));
}

これで反復練習用のテンプレートに作り変えることができる:

template staticMap(alias F, T...)
{
    alias A = AliasSeq!();
    static foreach (t; T)
        A = AliasSeq!(A, F!t); // ここにエイリアスの割り当て
    alias staticMap = A;
}

反復的なアプローチを使うことで、再帰的なテンプレートインスタンスの組み合わせによる爆発をなくすことができる。 テンプレートのインスタンス化の組み合わせによる爆発をなくし、それに伴う高いメモリコストとランタイムコストをなくすことができる、 また、テンプレートの入れ子の深さの制限の問題もなくなる。 再帰の深さが深い場合に発生するわかりにくいエラーメッセージもなくなる。

文法だ:

AliasAssign:
    Identifier = Type;

がDeclDefの展開に追加される。識別子(Identifier)は、辞書的に先行するエイリアス宣言(AliasDeclaration: AliasDeclaration)に解決されなければならない。 に解決されなければならない:

alias Identifier = Type;

Identifierが一致し、両者が同じTemplateDeclarationのメンバである。 セマンティック処理では、AliasAssignに遭遇すると、その中の"型"が置き換えられる。 AliasAssignの"型"は、対応するAliasDeclarationの"型"または以前にマッチした "型"を置き換える。 を置き換える。

AliasAssign文法は以前パーサーによって拒否されていた。 を追加しても、既存のコードが壊れることはない。

Dの最も優れた特徴のひとつは、Cコードとの統合が容易なことだ。 CコードとDコードのサブセット(DasBetterCと呼ばれる)の間には、ほぼ1対1のマッピングがある。 のサブセット(DasBetterCとして知られている)との間には、ほぼ1対1のマッピングがある。DとCのコードはお互いを直接呼び出すことができる。 を直接呼び出すことができる。

しかし、DはCのコードを直接読むことはできない。特に .h(または「ヘッダー」)ファイルの形で提供されている。 .hファイル内の宣言にアクセスし、それをDコードで利用できるようにするには、.hファイル内のC宣言を何らかの方法で利用しなければならない。 .hファイル内の宣言にアクセスし、それをDコードで利用できるようにするには、.hファイル内のC宣言を何らかの方法でDに翻訳しなければならない。 に翻訳しなければならない。 手作業で.hファイルをDに翻訳するのは難しくないが、面倒で煩わしい、 Dへの手翻訳は難しくはないが、面倒で厄介であり、Dを既存のCコードで使用する際の障壁となることは間違いない。 を既存のCコードで使用する際の障壁となる。

なぜ Dコンパイラーは、単に.hファイルを読んで、その宣言を抽出することができないのだろうか? なぜ「ただ動く」だけではないのか? Dは、単体テストだけでなく、ドキュメント生成も言語に統合することで大きな成功を収めてきた。 生成や単体テストを組み込むことに大きな成功を収めている。にもかかわらず 多くのドキュメント生成ツールやテスト・フレームワークが存在する、 それが組み込まれていて「ただ動く」というシンプルさは、変革をもたらすものだ。

Cプリプロセッサ

C言語そのものとは完全に区別された独自の言語である そのものとは完全に区別される。独自の文法、独自のトークン、独自のルールを持つ。 Cコンパイラーはプリプロセッサの存在にさえ気づかない。 (この2つは統合することができるが、意味的には何も知らないという事実は変わらない。 (両者は統合することができるが、それでも意味的には何も知らないという事実は変わらない)。 プリプロセッサはDとは十分に異なるので、プリプロセッサを直接翻訳する望みはない。 プリプロセッサのディレクティブをDに翻訳することは、最も表面的な方法以外では望めない。 プリプロセッサのディレクティブをC言語に置き換えることはできない。 をCに置き換えることができる。

これまでの解決策

htod by ウォルター・ブライト

htodはCの.hファイルをDソースファイルに変換する。 をDコードにインポートするのに適したDソースファイルに変換する。 htodは、Digital MarsのCおよびC++コンパイラのフロントエンドからビルドされている。 CやC++コンパイラと同じように動作するが、出力はオブジェクトではなくDモジュールのソースコードである。 オブジェクトコードではなく、Dモジュールのソースコードである。

Dステップ by ヤコブ・カールボーグ

DStepコード

Dステップの記事

記事より「DStepは、CやObjective-CライブラリのDバインディングを自動生成するツールである。 バインディングを自動生成するツールである。これは CまたはObjective-Cのヘッダーファイルを処理し、Dモジュールを出力する。 DStepはClangコンパイラーをライブラリー(libclang)として使用し、ヘッダーファイルを処理する。"

dpp by Átila Neves

dppコード

dpp記事

記事より「dppはコンパイラー・ラッパーである。 拡張子が.dppのDソースファイルを解析し、#includeディレクティブに遭遇した場合、その場所に展開する。 ディレクティブを展開し、CまたはC++のシンボルをすべてDに変換する。 その結果をDコンパイラー(デフォルトではDMD)に渡す。"

DStepと同様、dppもlibclangに依存している。

ISO C11コンパイラ「ImportC」の紹介

ここからが次のステップだ:

• Cプリプロセッサのことは忘れよう。
• C++を見過ごせ。
• Dフロントエンドに本物のISO C11コンパイラを入れよう。
• このユニークな機能を区別するために "ImportC"と呼ぶ。

詳しく説明する:

1. Cコードを直接コンパイルする。

gcc -E -P stdio.h >stdio.c

とDソース・ファイルにある:

import stdio; // stdio.cを読み込んでコンパイルする。

gccがすべてのプリプロセッサ作業を行うことで、100％動作互換性が保たれる。

2. Cコンパイラー・フロント・エンドは、統合されたプリプロセッサを取り除いた、単純な

3. dmdのDパートは、それがCコードから始まったとは知らないだろう。それは

ImportCをCコンパイラとして使う

Cコードをインポートする代わりに、dmdをスタンドアロンCコンパイラのように使ってCコードをコンパイルすることができる。 スタンドアロンCコンパイラのように使うことができる。

hello.cファイルを作成する:

int printf(const char*, ...);

int main()
{
    printf("hello world\n");
}

コンパイルして実行する:

dmd hello.c
./hello
hello world!

Cインクルードを使用するCコードの場合、CプリプロセッサでCソースを前処理することができる。 プリプロセッサでCソースを前処理することができる。testcode.cファイルを作成する:

#include <stdint.h>

uint32_t someCodeInC(uint32_t a, uint32_t b)
{
    return a + b;
}

CコードをCプリプロセッサで前処理する:

gcc -E -P testcode.c >testcode.i

Dファイルd_main.dを作成する:

import std.stdio;
import testcode;

void main()
{
    writeln("Result of someCodeInC(3,4) = ", someCodeInC(3, 4) );
}

コンパイルして実行する:

dmd d_main.d testcode.i
./d_main
Result of someCodeInC(3,4) = 7

.c'の代わりに'.i'という拡張子を使うことができる。これにより 前処理された中間Cコードが使用されていることを明確にする。.i'ファイルは、ジェネレーター・スクリプトやMakeファイルによって作成することができる。 .i'ファイルは、ジェネレーター・スクリプトやMakeファイルによって作成される。

実装の詳細

ユーザー体験

• エラーメッセージは控えめで実用的だ。

• エラーに遭遇した後のリカバリーはあまり発達していない。

• プリティ・プリンティングのコードはCではなくDシンタックスで行われる、

• 警告は出ない。ImportCはコーディングスタイルを気にしない、

• もしImportCのコードがメモリーを破損したり、バッファーをオーバーフローさせたりした場合、

• シンボリック・デバッグのサポートがある。

ISO C11との相違点

• Cプリプロセッサを持たない。

• タグ・シンボルはグローバル・シンボル・テーブルの一部であり、特別なタグ・シンボルではない。

• 文字リテラル内の複数文字はサポートされていない。

• _Atomic 型修飾子は無視される。

• _Atomic as型指定子は無視される。

• _Alignof は無視される。

• _Generic は実装されていない。

• const へのポインタは、Dのように推移的である。

• {initializer-list }は実装されていない。

• ( 型名 ) { initializer-list } は実装されていない。

• 複素数は実装されていない。

• ImportCでは前方参照が機能する。すべてのグローバルシンボルが見える

• Cのパース後に適用されるセマンティクスはDのセマンティクスであり、Cのセマンティクスではない、

処理系定義:振る舞い

C11規格は、多くの実装定義動作を認めている。 実装系定義:" がある。

• volatile restrict, , は受け入れられ、無視される。register _Noreturn

• char は符号なし

• inline は無視される。Dコンパイラーは、インライン化したいと思ったものをインライン化するからだ。

• long double Dコンパイラーはインライン化したいと思うものをインライン化するからだ。

エクステンション

セマンティック処理にDコンパイラーを使うことは、より良いDセマンティックを追加するための多くの誘惑を提供する。 を追加する誘惑が多い。Cの方言をまた新たに考案することは、ImportCの目的ではない。 ImportC "の目的ではない。しかし、役に立つものもある:

• コンパイル時の関数の実行。

これは使える。を使ってImportCのテストケースを書くのに便利だ。 _Static_assert.これはまた、DコンパイラがImportC関数をDと同じように実行できることを意味する。 関数を実行することができる。

未実装の拡張機能

• Cコードの多くは、ホストCコンパイラが提供する拡張機能を利用している。

• 代替キーワードは実装されていない。代替 キーワードをマクロとして定義することができる。

#define __attribute __attribute__
#define __asm       asm
#define __asm__     asm
#define __const     const
#define __const__   const
#define __inline    inline
#define __inline__  inline
#define __extension__

#include <stdlib.h>

今後の方向性

Cプリプロセッサ

これを組み込む何らかの手段が現実的かもしれない。今のところは、cpp、 warpまたはsppを使う。

CのマクロをDに変換する必要がある。 がこれを行う。

ImportC++ ?

いいえ、dppを使う。

ImportObjective-C ?

DStepを使う。

ドキュメンテーション

ImportCの詳細については、仕様書のページに書かれている。

デリゲートが組み込まれている言語(JavaScriptやC#など)からの新規参入者は、デリゲート/関数リテラルに。 から来た人は、デリゲート/関数リテラルに(args) => { /* body */ } 。

しかしDでは、この構文はdelegate を返すdelegate になる、 を返す。これはデバッグしにくいバグを引き起こす可能性がある、 したがって、現在では非推奨となっている。

デリゲートがデリゲートを返すというのが本当に意図された使い方であるなら、 か のどちらかを使うこと、 (args) { return () => /* body */; } か(args) => () { /* body */ } のどちらかを使う。

以下の機能/バグ修正/改善が に実装された:

• テンプレートミックスインの宣言がインスタンス化コンテキストに出力される。
• (スーパークラスの)メソッドのエイリアスは、using ... として出力される。typedef ...
• extern(D) 特定の状況下で、シンボルが誤って放出されることはなくなった。
• extern(D) 構造体とクラスは、エクスポートされたシンボルによって参照された場合に出力される。
• テンプレート宣言から参照されるシンボルは、最初に使用される前に生成される。
• 前方宣言は一貫してインクルードされるtemplate<...>
• extern(C++, class) extern(C++, struct) は前方宣言に影響する
• 参照パラメータで使用される型は、可能であれば前方宣言される。
• 名前変更されたインポートまたはローカル・インポートは、可能な限りusing ... として発行される。
• 複雑な型は_Complex 。
• 宣言は、最初のメンバアクセスの前に行われる。
• C++ で無効な名前のグローバル変数は省略される。
• union 変数/パラメータのイニシャライザは、非アクティブ・メンバを省略する。
• 型キャストは D のスタイルではなく、C のスタイルで出力される。cast(...) ...
• D ではstruct 継承が禁止されているため、構造体は常にfinal としてタグ付けされる。
• を使用した宣言に対するアサートがなくなった。noreturn
• シンボル名は常にテンプレート・パラメータとそれを囲む宣言を含む 必要な場合
• テンプレート化された集合体の(static / enum)メンバを適切に出力するようになった
• テンプレート宣言で静的配列を適切に出力するようになった
• __gshared 変数を参照する際に、親集約を省略しなくなった
• 単項式/二元式にネストされた式にD構文を使用しなくなった。
• 無名構造体/共用体の内部でpublic:,... を使用しなくなった
• 宣言シンボルへのエイリアスに対してtypedef を返さないようにした

注釈: ヘッダー・ジェネレーターはまだ実験的なものである。 バグがあればバグトラッカーに送ってほしい。

このプレビューによって、コンストラクタの内部で例外がスローされたときに、部分的に構築されたオブジェクトが適切に破棄されるようになる。 このプレビューは、コンストラクタの内部で例外がスローされたときに、部分的に構築されたオブジェクトが適切に破棄されることを保証する。これは 2.075で導入され、現在はデフォルトで有効になっている。

厳密な属性を持つコンストラクタが、より修飾度の低いデストラクタを呼び出すと、コードのコンパイルに失敗することがある。 を持つコンストラクタが、より修飾度の低いデストラクタを呼び出す可能性がある場合、コードのコンパイルに失敗することがある:

struct Array
{
    int[] _payload;
    ~this()
    {
        import core.stdc.stdlib : free;
        free(_payload.ptr);
    }
}

class Scanner
{
    Array arr;
    this() @safe {} // arr.~this()を呼び出すかもしれない
}

このようなコードは、コンストラクタをnothrow 、デストラクタが呼ばれないようにするか、フィールドのデストラクタを調整する必要がある。 が呼ばれないようにするか、フィールドのデストラクタを調整する必要がある。

コンパイラーは、 フラグが設定されていない限り、挿入されたデストラクター呼び出しによって引き起こされた属性違反に対してのみ修正を発行する。 ただし、-preview=dtorfields フラグが明示的に指定されている場合を除く。 フラグが明示的に指定されていない限り、挿入されたデストラクタ呼び出しに起因する属性違反に対してのみ、コンパイラは修正を発行する。

積分ベクトル型には、.min と.max プロパティを追加する。

浮動小数点ベクトル型の場合は、.min 、.max 、.min_normal を追加する、 .nan .infinity, および.epsilon プロパティを追加する。

これらのプロパティの値は、ベクトル・タイプにブロードキャストされたベクトル要素タイプに対応する値である。 要素型に対応する値である。つまり

import core.simd;

static assert(float4.max == cast(float4)float.max);

const またはimmutable の変数は、実行時に初期化されていてもスイッチ・ケースとして使用できるが、dmd 2.073.2 以降、ミュータブル変数の使用は非推奨となっている。 この非推奨は現在エラーになっている:

void foo(int s, int x, const int y, immutable int z) {
    switch (s) {
        case x: // エラー
        case y: // 許可
        case z: // 許可
        default:
    }
}

実行時変数が存在すると(たとえconst 、immutable であっても)、効率的なジャンプテーブルの代わりに、コード生成の前にスイッチ全体が一連のif-else文に下げられてしまうからである。case 文では、コンパイル時に既知の値のみを使用することをお勧めする。 ランタイム既知の変数のペアを比較する場合は、通常のif文を使用する。

不正なインデックス付けに起因するエラーには、配列の長さだけでなく、 、不正なインデックスも含まれるようになった。 配列の長さ、arr[bad] に対する違反インデックスが含まれるようになった、 の場合は配列の長さ、不正なスライスの場合はarr[bad1 .. bad2] 。

例:

void main()
{
    int[] a = [1, 2, 3];
    int b = a[7];
}

以前は、コンパイルして実行すると次のようなエラーが発生していた:

dmd -run main.d
core.exception.RangeError@main.d(4): Range violation
––––––––––
??:? _d_arrayboundsp [0x555765c167f9]
??:? _Dmain [0x555765c16752]

これで降伏する:

dmd -run main.d
core.exception.ArrayIndexError@main.d(4): index [7] exceeds array of length 3
––––––––––
??:? _d_arraybounds_indexp [0x5647250b980d]
??:? _Dmain [0x5647250b9751]

同様に、境界外のスライス操作の場合も同様である:

void main()
{
    int[] a = [1, 2, 3];
    int[] b = a[2 .. 4];
}

dmd -run main.d
core.exception.ArraySliceError@main.d(4): slice [2 .. 4] extends past array of length 3
––––––––––
??:? _d_arraybounds_slicep [0x5647250b980d]
??:? _Dmain [0x5647250b9751]

境界外のスライスコピー(arr[a..b] = arr[c..d] )や連想配列の存在しないキーへのインデックス付け(table["bad"] )に対するエラーメッセージは更新されていない。

クラス・アロケータはv2.080.0以降非推奨となった。

class C
{
    new(size_t size)
    {
        return malloc(size);
    }
}

でアノテーションされていないクラス・アロケータは、コンパイル・エラーになる。@disable でアノテーションされていないクラス・アロケータはコンパイル・エラーとなる。文法も変わるので 文法も変更されるため、空でないパラメータ・リストと関数本体を受け付ける古いスタイルのアロケータ構文に対する新しい非推奨メッセージがある。 空でないパラメータ・リストと関数本体を受け付ける。

class C
{
    @disable new(size_t size)   // 非推奨: 空でないパラメータリスト
    {
        return malloc(size);    // 非推奨: 関数定義
    }
}

是正措置の例:

class C
{
    @disable new();
}

非推奨機能のページ を参照のこと。

以下のコードは2.087.0から非推奨となった。

module foo;
immutable int bar;
static this()
{
    bar = 42;
}

これは問題である。というのも、モジュールのコンストラクタ(static this)は、スレッドが生成されるたびに実行されるからである。 また、immutable のデータは暗黙のうちにshared 、新しいスレッドが生まれるたびに値が上書きされることになる。 immutable 値は、新しいスレッドが生成されるたびにオーバーライドされる。

このようなコードを修正するには、`shared this static this`を使うことだ。 static this over static this`を使うことだ。

コマンド・ライン・スイッチ-target=<triple> を使うと、コンパイラがコードを生成するターゲットを指定できる。 コンパイラがコードを生成する対象を指定する。<triple> の書式は<arch>-[<vendor>-]<os>[-<cenv>[-<cppenv]] である。指定子の具体的な値は以下の表のとおりである。 以下の表に示す。

<arch>

アーキテクチャーとsubarchの機能は連結されているので、x86_64+avx2 は64ビットで、avx2 命令を持つ。

<vendor>

<os>

<os> はオペレーティング・システム指定子である。オプションで、 や のようにバージョン番号が続くこともある。Freebsdの場合、これは対応する定義済みの 識別子を設定する。例えば、 は を設定する。他のオペレーティング・システムでは、これは他のコンパイラーとの相互運用性を高めるためのものである。 darwin20.3.0 freebsd12 version freebsd12 version(FreeBSD12)

<cenv>

<cppenv>

<cppenv> はC++実行環境である。この指定子はオプションである。この指定子が存在する場合は、 指定子も存在しなければならない。 <cenv>

以下のコードは2.088.0から非推奨となった。

union U
{
    int a;
    long b = 4;
}

なぜなら、共用体は最初のフィールドのイニシャライザーが何であれ、デフォルトで初期化されるからである。 ユニオンはデフォルトで最初のフィールドのイニシャライザが何であれ初期化され、他のイニシャライザは無視されるからだ。

修正方法は、union フィールドを最初のフィールドとして宣言することである。 フィールドを宣言することである。

以前は、テンプレート引数は完全修飾されていなかった、 この場合、より長い名前になる。

TypeInfo_Struct インスタンスは、(大幅に短くなる可能性のある)「短い」名前だけを保存するようになった。 インスタンスは、(潜在的に短い)マングルされた名前のみを保存し、最初の または を呼び出したときに、(スレッドごとのキャッシュを使用して)遅延的にデマングルするようになった。そのため 構造体TypeInfoごとに一意な文字列が必要な場合は、計算された ( および 以外)よりも の方がよい。 非 )である。 name toString() name@nogc mangledNamepure

関連する変更:TypeInfo.toString() はpure ではなくなった。 TypeInfo_Struct 、名前キャッシュを分離した。 TypeInfo_Class.toString() その他はpure のままである。

fork()関数(またはlinuxではclone())をサポートするPosixシステムでは、「fork」GCオプションを有効にすることで、保守的/正確なGCを同時並行的に行うことができる、 例えば、コマンドラインに を追加する、あるいは、Posixシステムにfork()関数を組み込むなど、通常の方法でGCオプション'fork'を有効にすることで、保守的/高精度GCを並行化できる。 コマンドラインに--DRT-gcopt=fork:1 を追加する。

extern(C) __gshared string[] rt_options = [ "gcopt=fork:1" ];

をリンクしたバイナリに追加する(../spec/garbage.html#gc_config を参照)。

アプリケーションは実行を続け、フォークされたプロセスがヒープオブジェクトをマークしている間、新しいメモリがシステムから割り当てられる。 プロセスがヒープオブジェクトをマークしている間、アプリケーションは実行を続け、新しいメモリがシステムから確保される。アプリケーションの同時実行への影響を最小にするため、フォークされたプロセスはシングルスレッドしか使わない。 アプリケーションの同時実行への影響を最小にするためにシングルスレッドしか使わない。

これにより、"世界を止める"時間が短縮されるが、その代償として、より多くのメモリが必要となり、現在スキャン中のメモリへの書き込み時にページ保護のオーバーヘッドが発生する。 のオーバーヘッドを必要とする。

core/sys/linux/sys/procfs.d にlwpid_t シンボルが追加された。 O_CLOEXEC シンボルがcore/sys/posix/fcntl.d に追加された。

新しい関数isValidCodepoint がstd.utf に追加された。 これは、1つの文字が有効なコードポイントを形成しているかどうかをチェックするために使用できる。例えば 例:char 0x80 は有効なコードポイントではない。 は有効なコードポイントではない。 wcharä は有効な文字である:

assert(!isValidCodepoint(cast(char) 0x80));
assert(isValidCodepoint('ä'));

dubの設定ファイルに以下の項目が追加された:defaultEnvironments defaultBuildEnvironments,defaultRunEnvironments,defaultPreGenerateEnvironments,defaultPostGenerateEnvironments,defaultPreBuildEnvironments,defaultPostBuildEnvironments,defaultPreRunEnvironments,defaultPostRunEnvironments. これらは、プロジェクト固有の設定がない場合に使用される。

{
    "defaultEnvironments": {
        "VAR": "Foo"
    }
}

各プロジェクト固有の設定では、以下の項目が利用できる:environments buildEnvironments,runEnvironments,preGenerateEnvironments,postGenerateEnvironments,preBuildEnvironments,postBuildEnvironments,preRunEnvironments,postRunEnvironments.

JSONでは

{
    "environments": {
        "VAR": "Foo"
    }
}

SDLでは

environments "VAR" "Foo"