Форум на Исходниках.RU

D vs C++

Majestio — Fri, 22 May 2026 02:18:32 +0000

Majestio:

Цитата Qraizer @ 21.05.26, 18:23

Это ты кого... э-э-э... кем обозвал-то?

Я нечяянно, по синьке - а это щетай не щетается! :lol: Просто фильм вспомнился клёвый, ретро.

D vs C++

Qraizer — Thu, 21 May 2026 18:23:16 +0000

Qraizer: Это ты кого... э-э-э... кем обозвал-то? А то был тут у нас один "посетитель":

Цитата

— О, привет. А чё ты тут делаешь?
— Та вот, денег вам надо заплатить.
— :blink:

Я так и не понял, кто кому.

P.S. Честно пытался вспомнить, почему тогда замолчал. Не вспомнил. То ли МС-21 заканчивался, то ли SuperJet начинался.

D vs C++

Majestio — Thu, 21 May 2026 15:09:14 +0000

Majestio: Не, посоны!!! По-чесноку ... я знаю поговорку "На дураков не обижаются" ... Но я хотя бы попытался :lol:

D vs C++

Majestio — Thu, 21 May 2026 13:52:42 +0000

Majestio:

Цитата Qraizer @ 19.05.26, 16:47

P.S. Это VS2022, если что. Банальный ключик-O2

Кто людям помогает - тот тратит время зря!!! Хорошими делами прославиццо незя!!! (С)

Добавлено 21.05.26, 14:42

Цитата Qraizer @ 19.05.26, 16:47

P.S. Это VS2022, если что. Банальный ключик-O2

Ой, отлегло от души ... 12 мин искал, где можно Qraizer'а попытаться обидеть, и вот настал момент!!! :lol:

D vs C++

Qraizer — Tue, 19 May 2026 16:47:17 +0000

Qraizer: В смысле «мёртвый»? Вообще проектов нет, что ли?

Добавлено 19.05.26, 16:56

Цитата applegame @ 14.08.21, 10:27

Полюбуйтесь как плюсовой std::function безбожно сливает встроенным дешным лямбдам:
...

:huh:

Добавлено 19.05.26, 16:59
Удивили козла капустой. :D Нефик в ГНУсных портах работать:

#include <functional>

class Foo {

public:

virtual void foo(std::function<void()> f);

};

int bar(Foo* foo, int a, int b, int c, int d) {

int e;

foo->foo([&] { e = a + b + c + d; });

return e;

}

_TEXT SEGMENT

_<e>$ = 8 ; size = 4

_<a>$ = 12 ; size = 4

_<b>$ = 16 ; size = 4

_<c>$ = 20 ; size = 4

_<d>$ = 24 ; size = 4

??0<lambda_ac228c855dc2c6ed19d01a392d90130f>@@QAE@AAH0000@Z PROC ; <lambda_ac228c855dc2c6ed19d01a392d90130f>::<lambda_ac228c855dc2c6ed19d01a392d90130f>, COMDAT

; _this$ = ecx

; File D:\Work\CPPdel\q.cpp

; Line 10

mov eax, DWORD PTR _<e>$[esp-4]

mov DWORD PTR [ecx], eax

mov eax, DWORD PTR _<a>$[esp-4]

mov DWORD PTR [ecx+4], eax

mov eax, DWORD PTR _<b>$[esp-4]

mov DWORD PTR [ecx+8], eax

mov eax, DWORD PTR _<c>$[esp-4]

mov DWORD PTR [ecx+12], eax

mov eax, DWORD PTR _<d>$[esp-4]

mov DWORD PTR [ecx+16], eax

mov eax, ecx

ret 20 ; 00000014H

??0<lambda_ac228c855dc2c6ed19d01a392d90130f>@@QAE@AAH0000@Z ENDP ; <lambda_ac228c855dc2c6ed19d01a392d90130f>::<lambda_ac228c855dc2c6ed19d01a392d90130f>

_TEXT ENDS

; Function compile flags: /Ogtpy

; COMDAT ??R<lambda_ac228c855dc2c6ed19d01a392d90130f>@@QBE@XZ

_TEXT SEGMENT

??R<lambda_ac228c855dc2c6ed19d01a392d90130f>@@QBE@XZ PROC ; <lambda_ac228c855dc2c6ed19d01a392d90130f>::operator(), COMDAT

; _this$ = ecx

; File D:\Work\CPPdel\q.cpp

; Line 10

mov eax, DWORD PTR [ecx+16]

mov edx, DWORD PTR [ecx+12]

push esi

mov esi, DWORD PTR [eax]

mov eax, DWORD PTR [ecx+8]

add esi, DWORD PTR [edx]

add esi, DWORD PTR [eax]

mov eax, DWORD PTR [ecx+4]

add esi, DWORD PTR [eax]

mov eax, DWORD PTR [ecx]

mov DWORD PTR [eax], esi

pop esi

ret 0

??R<lambda_ac228c855dc2c6ed19d01a392d90130f>@@QBE@XZ ENDP ; <lambda_ac228c855dc2c6ed19d01a392d90130f>::operator()

_TEXT ENDS

; Function compile flags: /Ogtpy

; COMDAT ?bar@@YAHPAVFoo@@HHHH@Z

_TEXT SEGMENT

_e$ = -4 ; size = 4

_foo$ = 8 ; size = 4

_a$ = 12 ; size = 4

_b$ = 16 ; size = 4

_c$ = 20 ; size = 4

_d$ = 24 ; size = 4

?bar@@YAHPAVFoo@@HHHH@Z PROC ; bar, COMDAT

; File D:\Work\CPPdel\q.cpp

; Line 8

push ecx

; Line 10

sub esp, 40 ; 00000028H

; File C:\VS2022\VC\Tools\MSVC.44.35207\include\functional

; Line 855

lea ecx, DWORD PTR _e$[esp+44]

; File D:\Work\CPPdel\q.cpp

; Line 10

mov eax, esp

; File C:\VS2022\VC\Tools\MSVC.44.35207\include\functional

; Line 855

mov DWORD PTR [eax], OFFSET ??_7?$_Func_impl_no_alloc@V<lambda_ac228c855dc2c6ed19d01a392d90130f>@@X$$V@std@@6B@

mov DWORD PTR [eax+4], ecx

lea ecx, DWORD PTR _a$[esp+40]

mov DWORD PTR [eax+8], ecx

lea ecx, DWORD PTR _b$[esp+40]

mov DWORD PTR [eax+12], ecx

lea ecx, DWORD PTR _c$[esp+40]

mov DWORD PTR [eax+16], ecx

lea ecx, DWORD PTR _d$[esp+40]

mov DWORD PTR [eax+20], ecx

; File D:\Work\CPPdel\q.cpp

; Line 10

mov ecx, DWORD PTR _foo$[esp+40]

; File C:\VS2022\VC\Tools\MSVC.44.35207\include\functional

; Line 978

mov DWORD PTR [eax+36], eax

; File D:\Work\CPPdel\q.cpp

; Line 10

mov eax, DWORD PTR [ecx]

call DWORD PTR [eax]

; Line 11

mov eax, DWORD PTR _e$[esp+4]

; Line 12

pop ecx

ret 0

?bar@@YAHPAVFoo@@HHHH@Z ENDP ; bar

_TEXT ENDS

P.S. Это VS2022, если что. Банальный ключик-O2

D vs C++

Majestio — Tue, 19 May 2026 16:40:14 +0000

Majestio: :-?

D vs C++

D_KEY — Tue, 19 May 2026 06:03:21 +0000

D_KEY: Мертвый же язык. А так вроде были биндинги для gtk и qt

D vs C++

Majestio — Mon, 18 May 2026 16:05:20 +0000

Majestio: В телегу написал, но повторюсь тут ... Ну так за 5 (пять) лет появилось чо-то в D, с помощью которого можно без напряга гуячить и кроссплатформить?!!!

D vs C++

applegame — Sat, 14 Aug 2021 18:11:21 +0000

applegame:

Цитата D_KEY @ 14.08.21, 14:33

applegame, поясни за scope в данном кейсе, плиз.

Это чит :)
scope гарантирует компилятору, что лямбда не утечет за пределы скоупа функции. Соответственно компилятор может вместо аллоцирования замыкания на куче, просто передать в функцию указатель на контекст на стеке и указатель на функцию лямбды.

D vs C++

D_KEY — Sat, 14 Aug 2021 14:33:44 +0000

D_KEY: applegame, поясни за scope в данном кейсе, плиз.

D vs C++

korvin — Sat, 14 Aug 2021 14:21:59 +0000

korvin:

Цитата applegame @ 14.08.21, 10:27

Сравните ассемблерный выхлоп функции bar и самой лямбды.

Я ничего не понимаю в ассемблере.

Ocaml, Go.

D vs C++

OpenGL — Sat, 14 Aug 2021 11:34:22 +0000

OpenGL: Ну и раст тогда уж вдогонку

D vs C++

applegame — Sat, 14 Aug 2021 10:27:58 +0000

applegame: Полюбуйтесь как плюсовой std::function безбожно сливает встроенным дешным лямбдам:
C++: https://godbolt.org/z/jzo4aGfGb
D: https://godbolt.org/z/senjvanrW

Сравните ассемблерный выхлоп функции bar и самой лямбды.

D vs C++

applegame — Mon, 05 Aug 2019 13:32:31 +0000

applegame:

Цитата Qraizer @ 05.08.19, 03:49

Та не. Если её не одёрнуть __declspec(), она вообще в компайл-тайм константу 20 высчитывает.

Ну поэтому я и одергивал, компилятор D тоже так делает.

D vs C++

Qraizer — Mon, 05 Aug 2019 03:49:55 +0000

Qraizer:

Цитата applegame @ 04.08.19, 09:03

Визуалка видимо инлайнит

Та не. Если её не одёрнуть __declspec(), она вообще в компайл-тайм константу 20 высчитывает.

D vs C++

D_KEY — Sun, 04 Aug 2019 16:19:29 +0000

D_KEY:

Цитата applegame @ 04.08.19, 09:03

Если разнести эти функции, то такую оптимизацию в плюсах в принципе невозможно будет сделать.

А с -flto?

D vs C++

applegame — Sun, 04 Aug 2019 09:03:32 +0000

applegame:

Цитата Qraizer @ 31.07.19, 11:44

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

Визуалка видимо инлайнит. Если разнести эти функции, то такую оптимизацию в плюсах в принципе невозможно будет сделать.
Но в целом фигня. Мне бы плюсики с синтаксисом и метапрограммированием дешки и я, наверное, был бы счастлив.

D vs C++

korvin — Fri, 02 Aug 2019 20:17:53 +0000

korvin:

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

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

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

D vs C++

Qraizer — Wed, 31 Jul 2019 11:44:22 +0000

Qraizer:

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

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

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

D vs C++

applegame — Tue, 30 Jul 2019 23:43:21 +0000

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.

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

D vs C++

Qraizer — Tue, 30 Jul 2019 13:57:19 +0000

Qraizer:

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

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

D vs C++

D_KEY — Tue, 30 Jul 2019 13:31:12 +0000

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

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

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

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

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

D vs C++

applegame — Tue, 30 Jul 2019 13:22:53 +0000

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

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

D vs C++

Qraizer — Tue, 30 Jul 2019 11:20:14 +0000

Qraizer:

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

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

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

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

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

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

D vs C++

applegame — Tue, 30 Jul 2019 07:56:41 +0000

applegame:

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

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

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

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

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

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

D vs C++

Qraizer — Mon, 29 Jul 2019 22:30:38 +0000

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

D vs C++

D_KEY — Mon, 29 Jul 2019 18:18:25 +0000

D_KEY:

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

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

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

D vs C++

Qraizer — Mon, 29 Jul 2019 17:59:05 +0000

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 vs C++

amk — Sun, 28 Jul 2019 20:26:44 +0000

amk:

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

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

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

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

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

D vs C++

Qraizer — Sun, 28 Jul 2019 17:16:18 +0000

Qraizer:

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

void foo(std::function fn) {

Нахрена?

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

D vs C++

applegame — Sun, 28 Jul 2019 14:41:12 +0000

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 можно считать одинаковой, при прочих равных.

D vs C++

applegame — Sun, 28 Jul 2019 14:26:01 +0000

applegame:

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

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

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

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

Нахрена?

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

pragma(inline, false)

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

Добавлено 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;

}

D vs C++

D_KEY — Sun, 28 Jul 2019 14:13:54 +0000

D_KEY:

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

Прямой плюсовой аналог однозначно просрет дешному во всем

Вот мне помнится, что по крайней мере в скорости вызовов не просирает, а чуть ли не выигрывает :)
Если не лень, можешь померить.

Добавлено 28.07.19, 14:15

Цитата

__attribute((noinline))

Нахрена?

D vs C++

applegame — Sun, 28 Jul 2019 14:06:25 +0000

applegame:

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

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

У кого выигрывали? Я что-то не помню такого спора. Речь именно о типизированной лямбде, для передачи в нешаблонную функцию:

pragma(inline, false)

void foo(scope void delegate(int) fn) {

fn(10);

}

int bar() {

int i = 10;

foo((int x){

i += x;

});

return i;

}

Прямой плюсовой аналог однозначно просрет дешному во всем:

#include <functional>

__attribute((noinline))

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

fn(10);

}

int bar() {

int i = 10;

foo([&i](int x){

i += x;

});

return i;

}

В дешном аллокаций не будет, в плюсовом, насколько я понимаю, стопроцентно будет.

D vs C++

D_KEY — Sun, 28 Jul 2019 13:28:45 +0000

D_KEY: Ну если тебя не устроит auto f = ... или передача в шаблон функции, то нет. Но мне кажется, что о чем-то таком уже был спор тут и даже тесты были, где кресты все равно выиграли по скорости.

D vs C++

applegame — Sun, 28 Jul 2019 13:20:01 +0000

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

D vs C++

D_KEY — Sun, 28 Jul 2019 12:48:14 +0000

D_KEY:

Цитата JoeUser @ 28.07.19, 12:42

Цитата Flex Ferrum @ 28.07.19, 11:33

Надо придумывать новые!

Ну в нише мобильных устройств С++ таки подвинулся нехотя :lol:

Да он много где подвинулся. Просто не все хотят это признавать.

D vs C++

JoeUser — Sun, 28 Jul 2019 12:42:01 +0000

JoeUser:

Цитата Flex Ferrum @ 28.07.19, 11:33

Надо придумывать новые!

Ну в нише мобильных устройств С++ таки подвинулся нехотя :lol:

D vs C++

OpenGL — Sun, 28 Jul 2019 11:42:20 +0000

OpenGL: Явошарпы и go разве претендовали на замену плюсам? По-моему максимум на что они претендовали это на какую-либо нишу.

D vs C++

Flex Ferrum — Sun, 28 Jul 2019 11:33:49 +0000

Flex Ferrum: Заканчивалась вторая декада 21-го века. Люди всё ещё придумывали, чем бы им заменить С++. Варианты с Java, C#, D, Go и Rust уже пробовали... Надо придумывать новые! :D

D vs C++

applegame — Sun, 28 Jul 2019 07:28:59 +0000

applegame:

Цитата Wound @ 27.07.19, 19:14

D на какую область ориентирован? У него просто синтаксис с какой то встроенной библиотекой? Многопоточность, кросплатформенность на каком уровне? Какие библиотеки под него есть? Игры писать там? Веб? Десктоп? Или это просто какой то красивый синтаксис?

Область у D приблизительно совпадает с C/C++, но из-за достаточно удобного синтаксиса и быстрой компиляции он неплохо зашел в web и даже в скриптинг. С многопоточностью все отлично, с библиотеками не ахти, но к D можно прибиндить сишные и плюсовые либки. Так что игры писать можно. Без рантайма (а значит без GC и большой части стандартной либы) поддерживает, в принципе, все что поддерживают gcc и llvm. Полноценно поддерживаются x86/x86_64 Linux/Windows/MacOS/FreeBSD. Существуют неофициальные билды для Android и Raspberry PI.
Короче, если отклонился от официально поддерживаемых платформ - готовся к танцам с бубном. Например: Как на D писать под ARM

D vs C++

Wound — Sat, 27 Jul 2019 19:14:01 +0000

Wound: D на какую область ориентирован? У него просто синтаксис с какой то встроенной библиотекой? Многопоточность, кросплатформенность на каком уровне? Какие библиотеки под него есть? Игры писать там? Веб? Десктоп? Или это просто какой то красивый синтаксис?

D vs C++

applegame — Sat, 27 Jul 2019 18:51:39 +0000

applegame:

Цитата D_KEY @ 27.07.19, 18:21

А этим можно как-то управлять?

Можно заставить компилятор запретить операции с GC в нужном скоупе и не пользоваться этими операциями, заменяя их на RAII, RC (счетчики ссылок), а то и на старое доброе ручное управление памятью.

Цитата D_KEY @ 27.07.19, 18:21

Ну оптимизирующий компилятор - достаточно сложная штука, у C и C++ больше и ресурсов и наработок.

Во-первых, автор D - Уолтер Брайт, который сам является разработчиком хорошо известного в прошлом C++ компилятора. Во-вторых, вероятно, ты недооцениваешь оптимизации llvm и бекенда gcc. Все три компилятора D: dmd, gcc и ldc используюут один и тот же фронтенд. А вот бекенды у них разные. Результаты весьма отличаются.

D vs C++

D_KEY — Sat, 27 Jul 2019 18:21:52 +0000

D_KEY:

Цитата applegame @ 27.07.19, 17:30

Полностью отвязать в принципе невозможно, так как встроенные массивы и замыкания могут задействовать GC.

А этим можно как-то управлять?

Добавлено 27.07.19, 18:23

Цитата applegame @ 27.07.19, 18:01

Цитата D_KEY @ 27.07.19, 17:57

Ну круто, если так

D очень похож на плюсы, так что это не удивительно.

Ну оптимизирующий компилятор - достаточно сложная штука, у C и C++ больше и ресурсов и наработок.

D vs C++

applegame — Sat, 27 Jul 2019 18:01:11 +0000

applegame:

Цитата D_KEY @ 27.07.19, 17:57

Ну круто, если так

D очень похож на плюсы, так что это не удивительно.

D vs C++

D_KEY — Sat, 27 Jul 2019 17:57:34 +0000

D_KEY:

Цитата applegame @ 27.07.19, 17:30

а вот gdc (который уже в gcc) и ldc оптимизируют не хуже соответственно g++ и clang.

Ну круто, если так :)

D vs C++

applegame — Sat, 27 Jul 2019 17:55:25 +0000

applegame:

Цитата Qraizer @ 27.07.19, 17:40

А насколько просто переносится туда метакод оттуда?

Трудно сказать. Что-то простое переносится просто:

template<typename A> void foo(A a){ ... }

⇓

void foo(A)(A a){ ... }

Что-то более сложное может потребовать переписывания с нуля, включая алгоритмы и даже философию. Думаю, метапрограмминг в D тебе бы очень понравился, но в дизайне других мест понакосячено серьезно. Так что D умудряется вызывать восторг и ненависть одновременно. :lol:
Ну и я бы не стал писать на D код для авионики. :)

D vs C++

Qraizer — Sat, 27 Jul 2019 17:44:58 +0000

Qraizer:

Цитата applegame @ 27.07.19, 08:56

Не знаю, что ты подразумеваешь под "полноценные".

На джитхабе есть их, но все неполноценные. Например, требующие предоставить полный набор перекрывающих сигнатур. Или всего лишь двупараметрические. Без статических параметров. ...итп. А для полноценности требуются мультиметоды, максимально похожие на обычные функции: произвольная -арность, отсутствие ограничений на типы параметров, лишь некоторые из которых, указывается в прототипе, должны связываться в рантайм, перекрывающие сигнатуры не должны обязательно покрывать полный перебор вариантов, для не предоставленных вариантов должны применяться стандартные правила перегрузки most viable. Как минимум.

D vs C++

D_KEY — Sat, 27 Jul 2019 17:44:26 +0000

D_KEY:

Цитата JoeUser @ 27.07.19, 17:07

А если есть привычка не использовать ООП - переход будет труднее :)

Да, но людей с такой привычкой много, мейнстрим же.

D vs C++

Qraizer — Sat, 27 Jul 2019 17:40:04 +0000

Qraizer:

Цитата applegame @ 27.07.19, 08:56

Но все, что можно наметапрограммить в плюсах, можно наметапрограммить в D.

А насколько просто переносится туда метакод оттуда?

D vs C++

applegame — Sat, 27 Jul 2019 17:30:00 +0000

applegame:

Цитата D_KEY @ 27.07.19, 10:58

За D не скажу, но вроде тесты тоже не в его пользу попадались.

Есть и обратные тесты, где D обгоняет плюсья. Но это все синтетика, в которых если порыться выясняется, что код нихрена не эквивалентный. Референсный компилятор dmd довольно паршиво оптимизирует, а вот gdc (который уже в gcc) и ldc оптимизируют не хуже соответственно g++ и clang. В моей Fedora и gdc и ldc ставится из стандартных реп.

Цитата D_KEY @ 27.07.19, 11:26

Так они собираются убрать зависимость стандартной библиотеки от GC полностью или такой цели не стоит, а просто потихоньку убирают там, где можно обойтись?

Там где можно обойтись убирают. Полностью отвязать в принципе невозможно, так как встроенные массивы и замыкания могут задействовать GC.

Цитата D_KEY @ 27.07.19, 11:26

А наоборот?

Наоборот нет. В D полно метапрограмминга пока недоступного плюсам.
По мультиметодам нагуглил вариант реализации: https://github.com/jll63/openmethods.d
и блогпост посвященный ей же: https://dlang.org/blog/2017/08/28/open-methods-from-c-to-d/

D vs C++

JoeUser — Sat, 27 Jul 2019 17:07:20 +0000

JoeUser:

Цитата D_KEY @ 27.07.19, 17:03

И если их не надо или не обязательно менять, то переход будет легче

А если есть привычка не использовать ООП - переход будет труднее :)

D vs C++

D_KEY — Sat, 27 Jul 2019 17:03:23 +0000

D_KEY:

Цитата JoeUser @ 27.07.19, 15:27

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

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

Не факт. Все зависит от привычек.

Да, зависит от привычек. И если их не надо или не обязательно менять, то переход будет легче :)

D vs C++

JoeUser — Sat, 27 Jul 2019 15:27:46 +0000

JoeUser:

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

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

Не факт. Все зависит от привычек. Я вот тоже как только начал читать про Раст, сразу как-то воспринял в штыки, что в нем весь фарш ООП реализуется средствами синтаксиса частично. Остальное конечно тоже можно сделать, но чуть сложнее (если не ошибаюсь OpenGL показывал). Но если, к примеру, сравнить С++ и Раст, просто подход разный. У С++ основной подход - это реализация свойств путем объявления методов, наследования для расширения этого "набора свойств", виртуализации методов для переопределения свойств после наследования. У Раста другой подход - реализация поведений. Тоже подход, который имеет право на жысть, как основная концепция. Могу конечно ошибаться, пока только изучаю, но во многих статьях именно это ставят как особенность языка (не говоря конечно о заимствованиях и временах жизни).

D vs C++

D_KEY — Sat, 27 Jul 2019 13:46:01 +0000

D_KEY:

Цитата korvin @ 27.07.19, 12:05

Тогда почему ты указываешь это как критерий какого-то положительного качества языка?

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

D vs C++

korvin — Sat, 27 Jul 2019 12:05:55 +0000

korvin:

Цитата OpenGL @ 27.07.19, 11:21

Цитата Астарот @ 26.07.19, 21:47

Ну, и, разумеется, там пропущено "не".

Фак. И правда :lol:

С «не» да, слышал такой мем.

Добавлено 27.07.19, 12:10

Цитата D_KEY @ 27.07.19, 10:58

Нормальное не в смысле "правильное", а в смысле "привычное", "обыденное", как раз "мейнстримные"

Тогда почему ты указываешь это как критерий какого-то положительного качества языка?

D vs C++

OpenGL — Sat, 27 Jul 2019 11:40:53 +0000

OpenGL:

Цитата applegame @ 27.07.19, 08:56

RC-контейнеры

Что это за зверь?

D vs C++

D_KEY — Sat, 27 Jul 2019 11:26:49 +0000

D_KEY:

Цитата applegame @ 27.07.19, 08:56

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

Это хорошо. Так они собираются убрать зависимость стандартной библиотеки от GC полностью или такой цели не стоит, а просто потихоньку убирают там, где можно обойтись?

Цитата

Не знаю, что ты подразумеваешь под "полноценные". Но все, что можно наметапрограммить в плюсах, можно наметапрограммить в D.

А наоборот?

D vs C++

OpenGL — Sat, 27 Jul 2019 11:21:40 +0000

OpenGL:

Цитата korvin @ 26.07.19, 21:32

В первый раз слышу. Откуда это?

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

Цитата Астарот @ 26.07.19, 21:47

Ну, и, разумеется, там пропущено "не".

Фак. И правда :lol:

D vs C++

D_KEY — Sat, 27 Jul 2019 10:58:30 +0000

D_KEY:

Цитата applegame @ 27.07.19, 08:56

Странная фраза. Чего за ним угоняться-то? Компиляторы для эквивалентного кода в плюсах и D генерят абсолютно одинаковый асм. То же самое касается и сяшки и раста.

Разница есть даже между разными компиляторами C++. Rust если и у гонится, то только за счет llvm, но, насколько мне известно, пока сам компилятор оптимизации на уровне языка особых не делает. В отличие от того же clang. Т.е. только llvm.
За D не скажу, но вроде тесты тоже не в его пользу попадались.

Добавлено 27.07.19, 11:01

Цитата korvin @ 27.07.19, 09:51

Цитата D_KEY @ 26.07.19, 23:41

Как в мейнстрим языках. Классы, интерфейсы, наследование и т.п.

Почему ты считаешь, что оно и только оно — нормальное?

Нормальное не в смысле "правильное", а в смысле "привычное", "обыденное", как раз "мейнстримные"

D vs C++

korvin — Sat, 27 Jul 2019 09:51:16 +0000

korvin:

Цитата D_KEY @ 26.07.19, 23:41

Как в мейнстрим языках. Классы, интерфейсы, наследование и т.п.

Почему ты считаешь, что оно и только оно — нормальное?

D vs C++

applegame — Sat, 27 Jul 2019 08:56:23 +0000

applegame:

Цитата OpenGL @ 22.07.19, 08:15

Владение и заимствование в D. Что-то растом запахло

Тут не запахло, они реально делают это под влиянием идей раста. Правда с вполне конкретной целью. Они хотят библиотечно реализовать всякие RC-контейнеры и хотят сделать это максимально безопасно. Вот и пыжатся, чтобы нельзя было так просто поломать RC.

Цитата OpenGL @ 22.07.19, 11:57

Хз. Если выпилят GC и пойдут по тому же пути, что и раст - управление всеми ресурсами, включая память, через деструкторы, то может и смогут выехать на нормальном метапрограммировании.

Цитата D_KEY @ 23.07.19, 16:46

Ты про что? Про производительность? Тут за C++ вряд ли кто сможет угнаться.

Цитата Qraizer @ 24.07.19, 22:43

Кстати, applegame, всё хочу спросить, но постоянно забываю, так, что даже не помню, спрашивал ли уже: реально ли на D напрограммить полноценные мультиметоды? По идее, его метафичи равноценны плюсовым, так что почему бы и нет.

D vs C++

D_KEY — Fri, 26 Jul 2019 23:41:37 +0000

D_KEY:

Цитата korvin @ 26.07.19, 21:32

Цитата D_KEY @ 23.07.19, 16:46

а еще в нем уже есть нормальное ООП

Что такое «нормальное ООП»?

Как в мейнстрим языках. Классы, интерфейсы, наследование и т.п.

D vs C++

Астарот — Fri, 26 Jul 2019 21:47:26 +0000

Астарот:

Цитата korvin @ 26.07.19, 21:32

В первый раз слышу. Откуда это?

Есть подозрение, что это про Скалу. Ну, и, разумеется, там пропущено "не".

D vs C++

korvin — Fri, 26 Jul 2019 21:32:25 +0000

korvin:

Цитата D_KEY @ 23.07.19, 16:46

а еще в нем уже есть нормальное ООП

Что такое «нормальное ООП»?

Добавлено 26.07.19, 21:33

Цитата OpenGL @ 25.07.19, 05:54

хаскелевский мем "программа либо компилится, либо работает как надо"

В первый раз слышу. Откуда это?

D vs C++

OpenGL — Thu, 25 Jul 2019 05:54:38 +0000

OpenGL:

Цитата Wound @ 24.07.19, 19:01

Хотелось бы четко понимать, где Rust или D будут лучше, остальных.

Это слишком срачегенераторная формулировка вопроса :) Исходить надо из плюсов языка, и уже за их счёт определять, насколько они важны лично для тебя и в твоих проектах. Для раста, например, таковые это строгие статические проверки. В нём у тебя у каждой сущности есть своё время жизни, при взятии ссылок компилятор за всеми временами жизни следит и, если обнаруживается несоответствие, отказываться компилить. Это даёт возможность выражать в дизайне API условия навроде "вектор нельзя изменять пока есть итераторы на него". Также есть инструменты, позволяющие сказать, что некий класс нельзя юзать из другого потока. Например, класс Rc, который является аналогом плюсового shared_ptr, но без атомарного счётчика ссылок, очевидно, нельзя заюзать не в том потоке, в котором ты его создал, и не даст тебе сделать это именно компилятор, а не рантайм. Из минусов (хотя это и плюс тоже :) ) всего этого - необходимо лучше продумывать архитектуру и чётко понимать, кто кем у тебя должен владеть, так что для "херак и в продакшн" раст не годится совершенно. И в итоге всё это делает хаскелевский мем "программа либо компилится, либо работает как надо" в какой-то степени верным и для раста. За D не скажу подробно, это applegame надо звать, либо читать тему с самого начала.

D vs C++

Qraizer — Wed, 24 Jul 2019 22:43:27 +0000

Qraizer: Кстати, applegame, всё хочу спросить, но постоянно забываю, так, что даже не помню, спрашивал ли уже: реально ли на D напрограммить полноценные мультиметоды? По идее, его метафичи равноценны плюсовым, так что почему бы и нет.

D vs C++

Wound — Wed, 24 Jul 2019 19:01:17 +0000

Wound: А какая у этих языков ниша?

Добавлено 24.07.19, 19:03
Хотелось бы четко понимать, где Rust или D будут лучше, остальных. Или это просто для релакса языки?

D vs C++

D_KEY — Wed, 24 Jul 2019 18:35:40 +0000

D_KEY: Да, я сначала сюда кинул, а потом прочел :)

D vs C++

OpenGL — Wed, 24 Jul 2019 18:27:15 +0000

OpenGL: Оригинал 2015 года :D

Добавлено 24.07.19, 18:30
Думаю, где я видел шутку про "день ног" в программировании. Оказывается, я уже читал перевод ответа на эту статью Александреску :D

D vs C++

D_KEY — Wed, 24 Jul 2019 18:23:52 +0000

D_KEY: Александреску(перевод на Хабре)
Какой язык — D, Go или Rust имеет лучшие перспективы заменить C и почему?

D vs C++

OpenGL — Wed, 24 Jul 2019 18:20:41 +0000

OpenGL:

Цитата D_KEY @ 24.07.19, 17:51

Или это норм?

Я не знаю :-? Это вычисление цифр числа пи, и в сишных исходниках тоже юзается gmp. Странный какой-то тест.

D vs C++

D_KEY — Wed, 24 Jul 2019 17:51:04 +0000

D_KEY:

Цитата OpenGL @ 24.07.19, 17:42

unsafe там только для использования gmp юзается в одном тесте.

gmp как бы сишная либа :) Даже с asm местами.
Или это норм? :)
Там ещё в коде почему-то делают "сишные" структуры через #[repr©]. Интересно, зачем?

Надо будет как-нибудь таки потакать палочкой.

D vs C++

OpenGL — Wed, 24 Jul 2019 17:42:01 +0000

OpenGL:

Цитата D_KEY @ 24.07.19, 17:25

Мне лень смотреть, но скорее всего на крестах код написан так себе, а в коде на rust полно unsafe.

Правильно, зачем бегло посмотреть в течение 10 секунд, если за пять можно сгенерировать глупое предположение? :D unsafe там только для использования gmp юзается в одном тесте.

Цитата D_KEY @ 24.07.19, 17:25

А там сравнивают с gcc. Это вообще может быть фактически тест gcc vs llvm

Вот это, вероятно, более состоятельный аргумент.

D vs C++

D_KEY — Wed, 24 Jul 2019 17:25:21 +0000

D_KEY:

Цитата OpenGL @ 24.07.19, 17:17

Цитата D_KEY @ 23.07.19, 16:46

Тут за C++ вряд ли кто сможет угнаться.

И всё же местами раст оказывается быстрее.

Мне лень смотреть, но скорее всего на крестах код написан так себе, а в коде на rust полно unsafe. Насколько я понимаю, сам раст мало делает оптимизаций и там она идет на уровне llvm. И если это так, то странно было бы ожидать от раста производительности си или крестов.

Добавлено 24.07.19, 17:27
А там сравнивают с gcc. Это вообще может быть фактически тест gcc vs llvm :)
Честнее сравнить с clang на той же версии llvm.