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

[applegame]

Цитата korvin @ 17.11.15, 21:50

Нет, если доступ требует владения, как в случае с shared_ptr.

Доступ никогда не требует владения (по крайней мере в D/C++). Для получения доступа к объекту внутри shared_ptr/unique_ptr не обязательно передавать владение, можно просто вытащить указатель с помощью get(). Владения, в том числе и совместного, может требовать архитектура приложения, но не доступ сам по себе.

Цитата korvin @ 17.11.15, 21:50

Э-э... Если ты ждешь пока потоки завершатся, то зачем тебе GC, если объект прекрасно и безопасно удалится создателем? Полезность GC проявляется как раз, когда ты не ждешь, пока потоки, обрабатывающие объект, завершатся, поэтому ты не можешь сам удалить объект там, где создал.

Это был просто пример. Я так не делаю.

Цитата D_KEY @ 17.11.15, 22:07

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

Скорее всего никак не похоливарим. Я пытался начать писать, все равно получается портянка. Но я попробую позже.

Сообщение отредактировано: applegame - 18.11.15, 08:51

[Qraizer]

Цитата applegame @ 18.11.15, 08:51

Для получения доступа к объекту внутри shared_ptr/unique_ptr не обязательно передавать владение, можно просто вытащить указатель с помощью get().

А ещё можно вытащить символьный массив из строки std::basic_string<>::c_str(). А ещё динамический массив из вектора &std::vector<>::front(). Вопрос только, зачем. Ответ известен: для передачи легаси-коду. Совет: для иных целей использовать не следует.

[applegame]

Цитата Qraizer @ 18.11.15, 12:11

А ещё можно вытащить символьный массив из строки std::basic_string<>::c_str(). А ещё динамический массив из вектора &std::vector<>::front(). Вопрос только, зачем. Ответ известен: для передачи легаси-коду. Совет: для иных целей использовать не следует.

Это не отменяет того факта, что доступ к объекту не требует владения этим объектом. Кроме того почему обязательно легаси? Любому коду не работающему с shared_ptr/unique_ptr, например разнообразного рода API операционых систем или библиотек.

Сообщение отредактировано: applegame - 18.11.15, 14:12

[Qraizer]

Это тоже легаси.

[applegame]

Цитата Qraizer @ 18.11.15, 14:33

Это тоже легаси.

Все, что не умные плюсовые указатели - легаси

[Qraizer]

И не только.

[korvin]

Цитата Qraizer @ 18.11.15, 12:11

А ещё можно вытащить символьный массив из строки std::basic_string<>::c_str(). А ещё динамический массив из вектора &std::vector<>::front().

О, кстати, а ещё вот что недавно узнал:

public static void toUpperCase(String orig) {
    try {
        Field stringValue = String.class.getDeclaredField("value");
        stringValue.setAccessible(true);
        stringValue.set(orig, orig.toUpperCase().toCharArray());
    } catch (Exception ex){
    }
}

Иммутабельность? Не, не слышал.

[applegame]

По поводу возможности писать на D без GC. Человек, написал полностью на D кроссплатформенный VST-плагин для наложения на голос эффектов в реальном времени с околонулевой латентностью.
http://forum.dlang.org/thread/hbmbztydvyfw...forum.dlang.org

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

[korvin]

Ну вот, наконец-то нормальная success-story. =) Больше таких и D, может-таки, завоюет популярность у масс. =)

Правда, неплохо бы показать преимущества реализации этой задачи на D вместо C++.

[applegame]

Цитата korvin @ 27.11.15, 20:22

Ну вот, наконец-то нормальная success-story. =) Больше таких и D, может-таки, завоюет популярность у масс. =)

success-stories есть немного тут - http://wiki.dlang.org/Current_D_Use

Цитата korvin @ 27.11.15, 20:22

Правда, неплохо бы показать преимущества реализации этой задачи на D вместо C++.

Да какие тут преимущества? Любит человек писать на D вот и пишет. Преимущества по большей части субъективные - просто удобнее писать. Я приводил всякие куски кода в этой теме, но в ответ всегда заявлялось, что тоже самое можно сделать и на плюсах. Ну и что, что код в два раза длиннее и "мусорнее"? "Мусорность" ведь тоже понятие субъективное.

Всегда найдется, тот кому вот это

int[string][char][ushort] data;

кажется ничем не лучше, а то и хуже, чем вот это

map<unsigned short, map<char, map<string, int>>> data;

[D_KEY]

Цитата applegame @ 27.11.15, 21:27

Всегда найдется, тот кому вот это

int[string][char][ushort] data;

кажется ничем не лучше, а то и хуже, чем вот это

map<unsigned short, map<char, map<string, int>>> data;

Мне оба варианта кажутся отстоем. Я бы затайпдефил по частям. Иначе так и неясно кто на ком стоял и зачем.

[korvin]

Цитата applegame @ 27.11.15, 21:27

Всегда найдется, тот кому вот это

int[string][char][ushort] data;

кажется ничем не лучше, а то и хуже, чем вот это

map<unsigned short, map<char, map<string, int>>> data;

Тут я соглашусь с D_KEY'ем, но по другой причине: первый вариант напоминает объявление массива, вложенность типов как-то не отображается визуально, да и вообще определение типа как будто записано в обратном порядке. Всё же map проще и привычней воспринимать в виде keyT->valT, а не valT[keyT].

Т.е., если не принимать во внимание тайпдеф, то, ИМХО, логичней и понятней было бы что-то вроде

ushort->(char->(string->int)) data;

скобки при этом могут быть не обязательны. =)
или

ushort:char:string:int data;

Может, я просто привык к объявлению типа справа от идентификатора:

var data map[uint16]map[rune]map[string]int

или Pascal-style:

var data : map Word to map Char to map String to Integer;

=)

[D_KEY]

Мне кажутся самими приемлемыми варианты:

map[ushort, map[char, map[string, int]]]
ushort->char->string->int
ushort to char to string to int

[korvin]

Цитата D_KEY @ 27.11.15, 23:22

Мне кажутся самими приемлемыми варианты:

map[ushort, map[char, map[string, int]]]
ushort->char->string->int
ushort to char to string to int

Тоже норм. Первый мне особенно нравится, хоть он и длинней остальных, зато наглядно показывает вложенность. И при этом достаточно обобщённый, т.е. его можно применять для любых параметрических типов, например

keypath = Tuple[ushort, char, string];

[D_KEY]

Его проблема в том, скорее всего, придётся отказаться от оператора [](как и пришлось в scala), а это тоже неудобно.