D vs C++ , почти сурковская пропаганда: не пора ли C++ потихоньку готовиться к пенсии?

[applegame]

Цитата D_KEY @ 28.07.19, 14:13

Вот мне помнится, что по крайней мере в скорости вызовов не просирает, а чуть ли не выигрывает

Скорость вызова одинакова, я зырил асм.

Цитата D_KEY @ 28.07.19, 14:13

Нахрена?

Затем же зачем и

pragma(inline, false)

Иначе и clang и ldc оптимизируют bar в нуль: вернуть 20.

Добавлено 28.07.19, 14:32
Сравниваем шаблонные версии:
D:

pragma(inline, false)
void foo(alias fn)() {
    fn(10);
}
 
int bar() {
    int i = 10;
    foo!((int x){
        i += x;
    });
    return i;
}

template<typename F>
__attribute((noinline))
void foo(F fn) {
    fn(10);
}
 
int bar() {
    int i = 10;
    foo([&i](int x){
        i += x;
    });
    return i;
}

[applegame]

Смотрим асм.
D:

int example.bar():
        push    rax
        mov     dword ptr [rsp], 10
        mov     rdi, rsp
        call    pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo()@PLT
        mov     eax, dword ptr [rsp]
        pop     rcx
        ret
 
pure nothrow @nogc @safe void example.foo!(example.bar().__lambda1(int)).foo():
        add     dword ptr [rdi], 10
        ret

С++:

bar():                                # @bar()
        push    rax
        mov     dword ptr [rsp + 4], 10
        lea     rdi, [rsp + 4]
        call    void foo<bar()::$_0>(bar()::$_0)
        mov     eax, dword ptr [rsp + 4]
        pop     rcx
        ret
 
void foo<bar()::$_0>(bar()::$_0):                 # @"void foo<bar()::$_0>(bar()::$_0)"
        add     dword ptr [rdi], 10
        ret

В данном случае дешный асм либо равен либо лучше плюсового. Так то.

Добавлено 28.07.19, 15:10
Но это все ситуативные оптимизации. Полагаю, что производительность C++ и D можно считать одинаковой, при прочих равных.

[Qraizer]

Цитата applegame @ 28.07.19, 14:06

void foo(std::function<void(int)> fn) {

Нахрена?

Добавлено 28.07.19, 17:17
А, сорри, страничка новая.

[amk]

Цитата applegame @ 28.07.19, 13:20

А вот можно ли в плюсах создать "типизированную" лямбду (std::function<void(int)> например) с замыканиями, но без аллокаций в куче?

Цитата D_KEY @ 28.07.19, 13:28

Ну если тебя не устроит auto f = ... или передача в шаблон функции, то нет.

Насколько я понимаю, нет синтаксиса, чтобы типизировать лямбду явно. А неявно компилятор в любом случае её типизирует (поскольку с нетипизированными объектами работать не умеет)
И, насколько понимаю, для замыкания всегда выделяется память в стеке.

[Qraizer]

Цитата amk @ 28.07.19, 20:26

И, насколько понимаю, для замыкания всегда выделяется память в стеке.

Для замыканий память по любому нужна. Хоть какая-нибудь где-то там. Вопрос "можно ли без аллокаций", думаю, надо понимать как "можно ли без dynamic storage".

Добавлено 29.07.19, 18:07
Вопрос в другом: почему хочется без dynamic storage? ИМХО только лишь из-за проблем с производительностью и отсутствием явных языковых правил для dynamic storage duration. С GC можно было бы не париться за duration, но вопрос производительности только ужесточился бы. std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator(), а значит не может не быть полиморфным, а значит в объектной модели C++ должен работать с объектами косвенно, а значит посредством dynamic storage и указателями. Причём с подсчётом ссылок, ибо иначе std::function<> не имел бы семантику значений.

[D_KEY]

Цитата Qraizer @ 29.07.19, 17:59

std::function<> должен быть готов работать с любым объектом, чей интерфейс имеет реализацию указанного operator()

Делегаты в D обладают подобным же свойством.

[Qraizer]

Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон.

[applegame]

Цитата Qraizer @ 29.07.19, 17:59

Для замыканий память по любому нужна. Хоть какая-нибудь где-то там.

Какая-нибудь нужна, но в D нередко можно обойтись без дополнительной памяти для замыканий. Ни стековой ни dynamic storage ни GC. Плюсы́ такого фокуса, ЕМНИП, не умеют.

Цитата Qraizer @ 29.07.19, 22:30

Но я-то за Плюсы. Динамический полиморфизм за интерфейсом скрывает информацию об исходном типе, однако её сохраняет статический полиморфизм. Так что да, где спасовал std::function<>, вывозит шаблон.

Ну этот подход работает и в D, так что здесь преимуществ нет.

Сообщение отредактировано: applegame - 30.07.19, 07:59

[Qraizer]

Цитата applegame @ 30.07.19, 07:56

Ни стековой ни dynamic storage ни GC.

Каким образом?

Цитата applegame @ 30.07.19, 07:56

Ну этот подход работает и в D, так что здесь преимуществ нет.

Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен. Другое дело шаблон, он недостатка не имеет.

[applegame]

Цитата Qraizer @ 30.07.19, 11:20

Каким образом?

Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет. Я приводил пример:

void foo(scope void delegate(int) fn) {
    fn(10);
}
 
int bar() {
    int i = 10;
    foo((int x){
        i += x;
    });
    return i;
}

В данном случае в foo передается делегат, время жизни которого, меньше, чем переменной замыкания i. Компилятор знает, что делегат никуда не утечет из функции foo, благодаря атрибуту scope. В foo будет передан указатель на функцию делегата и указатель на стековый фрейм с переменной i.

Цитата Qraizer @ 30.07.19, 11:20

Причём тут преимущества? Я за недостатки. Просто иначе std::function<> не может быть устроен.

А, окай, я тебя неверно понял.

Цитата Qraizer @ 30.07.19, 11:20

Другое дело шаблон, он недостатка не имеет.

Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями.

Сообщение отредактировано: applegame - 30.07.19, 13:26

[D_KEY]

А какие преимущества перед шаблоном в данном случае?

Добавлено 30.07.19, 13:32

Цитата applegame @ 30.07.19, 13:22

Но есть другой недостаток: например, нельзя сделать массив лямбд с одинаковой сигнатурой, но разными замыканиями.

А для такого случая эта штука со scope как будет работать?

[Qraizer]

Цитата applegame @ 30.07.19, 13:22

Если время жизни лямбды меньше времени жизни переменных замыкания, то можно не резервировать дополнительную память, а обращаться напрямую к данным на стеке. D так умеет

Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется.

[applegame]

Цитата D_KEY @ 30.07.19, 13:31

А какие преимущества перед шаблоном в данном случае?

Даже с шаблоном под замыкания в плюсовой лямбде будет выделена память как минимум на стеке. Например, на стеке лежит переменная, а в замыкании ссылка на эту переменную. Ну и template code bloat никто не отменял.

Цитата D_KEY @ 30.07.19, 13:31

А для такого случая эта штука со scope как будет работать?

К такой штуке scope не прикрутишь никак. Тут будут аллокации в GC. Либо можно как в плюсах хранить функторы аналогичные std::function.

Цитата Qraizer @ 30.07.19, 13:57

Так это просто оптимизация. Оптимизировать и C++ умеет. Для общего-то случая такая оптимизация не гарантируется.

Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope.

Но в целом это мелочь, я считаю. Но интересная, на мой взгляд.

Сообщение отредактировано: applegame - 30.07.19, 23:46

[Qraizer]

Цитата applegame @ 30.07.19, 23:43

Плюсы не смогут сделать такую оптимизацию в общем случае. В плюсах нет scope.

Во-первых, это сделано в твоём собственном листинге вверху. Я даже проверил, визуалка тоже так умеет. Во-вторых, в Плюсах нет и Cёвого restrict. По той же причине, подозреваю, почему нет scope.

[korvin]

Цитата D_KEY @ 27.07.19, 13:46

Потому, что будет легче на него перейти и переводить существующие системы на него.

Ну вон в Go нет «нормального ООП» и вообще никакого параметрического полиморфизма, да и обработка ошибок не «нормальная» (привычна разве что для махровых Сишников). Каналы, опять же, для многих «программистов на мейнстримных языках» — не сильно привычный способ синхронизации. Но достаточно много людей его таки начали использовать.