Есть ли в D что-то похожее на семантику перемещения C++0x?

Я считаю, что в D есть несколько мест (например, возвращаемые структуры), где D удается заставить их перемещаться, тогда как C++ сделал бы их копиями. IIRC, компилятор будет выполнять перемещение, а не копирование в любом случае, когда он может определить, что копия не нужна, поэтому копирование структуры будет происходить реже в D, чем в C++. И, конечно же, поскольку классы являются ссылками, у них вообще нет проблемы.

Но несмотря на это, конструкция копирования уже работает в D иначе, чем в C++. Как правило, вместо объявления конструктора копирования вы объявляете конструктор постблита: this(this). Он выполняет полный memcpy перед вызовом this(this), и вы вносите только те изменения, которые необходимы для обеспечения того, чтобы новая структура была отделена от исходной (например, при необходимости выполнялась глубокая копия переменных-членов), в отличие от создания совершенно новой структуры. конструктор, который должен все скопировать. Итак, общий подход уже немного отличается от C++. Также общепризнанно, что структуры не должны иметь дорогостоящих конструкторов постблитов - копирование структур должно быть дешевым - так что это не такая проблема, как в C++. Объекты, которые было бы дорого копировать, обычно представляют собой либо классы, либо структуры со ссылкой или семантикой COW.

Контейнеры, как правило, являются ссылочными типами (в Phobos это структуры, а не классы, поскольку им не нужен полиморфизм, но их копирование не копирует их содержимое, поэтому они по-прежнему являются ссылочными типами), поэтому их копирование не требует больших затрат. как это было бы в C++.

В D вполне могут быть случаи, когда он мог бы использовать что-то похожее на конструктор перемещения, но в целом D был разработан таким образом, чтобы уменьшить проблемы, которые C++ имеет с копированием объектов вокруг, так что это далеко не проблема. что это на С++.

Я думаю, что все ответы полностью не ответили на исходный вопрос.

Во-первых, как указано выше, вопрос актуален только для структур. Классы не имеют осмысленного хода. Также указано выше, что для структур определенное количество перемещений будет происходить автоматически компилятором при определенных условиях.

Если вы хотите получить контроль над операциями перемещения, вот что вам нужно сделать. Вы можете отключить копирование, аннотировав это (это) с помощью @disable. Затем вы можете переопределить constructor(constructor &&that) C++, определив this(Struct that). Точно так же вы можете переопределить назначение с помощью opAssign(Struct that). В обоих случаях вам нужно убедиться, что вы уничтожили значения that.

Для присваивания, поскольку вам также нужно уничтожить старое значение this, самый простой способ — поменять их местами. Таким образом, реализация unique_ptr C++ будет выглядеть примерно так:

struct UniquePtr(T) {
    private T* ptr = null;

    @disable this(this); // This disables both copy construction and opAssign

    // The obvious constructor, destructor and accessor
    this(T* ptr) {
        if(ptr !is null)
            this.ptr = ptr;
    }

    ~this() {
        freeMemory(ptr);
    }

    inout(T)* get() inout {
        return ptr;
    }

    // Move operations
    this(UniquePtr!T that) {
        this.ptr = that.ptr;
        that.ptr = null;
    }

    ref UniquePtr!T opAssign(UniquePtr!T that) { // Notice no "ref" on "that"
        swap(this.ptr, that.ptr); // We change it anyways, because it's a temporary
        return this;
    }
}

Изменить: обратите внимание, что я не определял opAssign(ref UniquePtr!T that). Это оператор присваивания копии, и если вы попытаетесь определить его, компилятор выдаст ошибку, потому что вы объявили в строке @disable, что у вас нет такой вещи.

D имеют отдельную семантику значения и объекта:

• если вы объявите свой тип как struct, он будет иметь семантическое значение по умолчанию
• если вы объявите свой тип как class, он будет иметь объектную семантику.

Теперь, предполагая, что вы не управляете памятью самостоятельно, как это делается по умолчанию в D — используя сборщик мусора — вы должны понимать, что объекты типов, объявленных как class, автоматически являются указателями (или «ссылками», если хотите) на реальный объект, а не сам реальный объект.

Итак, при передаче векторов в D вы передаете ссылку/указатель. Автоматически. Копия не задействована (кроме копии ссылки).

Вот почему D, C#, Java и другие языки не «нуждаются» в движущейся семантике (поскольку большинство типов являются семантикой объекта и управляются по ссылке, а не по копированию).

Может быть, они могли бы реализовать это, я не уверен. Но действительно ли они получат прирост производительности, как в C++? По природе это маловероятно.

У меня почему-то возникает ощущение, что на самом деле ссылки на rvalue и вся концепция «семантики перемещения» являются следствием того, что в С++ нормально создавать локальные «временные» объекты стека. В D и большинстве языков сборщика мусора чаще всего объекты находятся в куче, а затем нет накладных расходов, связанных с копированием (или перемещением) временного объекта несколько раз при его возврате через стек вызовов, поэтому нет необходимости в механизме, чтобы избежать этих накладных расходов.

В D (и большинстве языков GC) объект class никогда не копируется неявно, и большую часть времени вы только передаете ссылку, поэтому это может означать, что вам не нужны ссылки на rvalue для их.

OTOH, объекты struct НЕ должны быть «дескрипторами ресурсов», а должны быть простыми типами значений, ведущими себя аналогично встроенным типам - так что, опять же, здесь нет причин для какой-либо семантики перемещения, ИМХО.

Это приведет к выводу, что у D нет ссылок на rvalue, потому что они ему не нужны.

Однако я не использовал ссылки rvalue на практике, я только читал их, поэтому я мог пропустить некоторые реальные случаи использования этой функции. Пожалуйста, относитесь к этому сообщению как к набору мыслей по этому вопросу, которые, надеюсь, будут вам полезны, а не как к надежному суждению.

Я думаю, если вам нужен источник, чтобы потерять ресурс, у вас могут быть проблемы. Однако, получив GC, вы часто можете избежать необходимости беспокоиться о нескольких владельцах, поэтому в большинстве случаев это может не быть проблемой.