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

Цитата MyNameIsIgor @ 12.11.15, 15:52

Но это не означает, что мне нужна эта гарантия через побитовую неизменяемость.

Возможно, но аргументация через то, что объект окажется в памяти с защитой от записи и всё упадёт - так себе. Ведь компилятор вполне может (и должен) реагировать на ситуации когда мы явно указываем (mutable), что нечто будет меняться.

Цитата DarkEld3r @ 12.11.15, 16:00

Цитата MyNameIsIgor @ 12.11.15, 15:52

Но это не означает, что мне нужна эта гарантия через побитовую неизменяемость.

Возможно, но аргументация через то, что объект окажется в памяти с защитой от записи и всё упадёт - так себе. Ведь компилятор вполне может (и должен) реагировать на ситуации когда мы явно указываем (mutable), что нечто будет меняться.

Если мы допускаем mutable, то мы опять приходим к "чем это отличается от openFile".
Дилемма ясна - либо такой вот кастрат, либо развитие системы типов для возможности через неё точнее выражать семантику кода.

Цитата DarkEld3r @ 12.11.15, 15:49

Кстати, D вообще никак не позволяет нарушить иммутабельность? Даже через всякие хаки?

Конечно можно, как в плюсах - cast'ом, но если поставить @safe, то нельзя, но если сильно захотеть и поставить @trusted, то можно. D - такой D.
Имутабельность в D скорее защита от случайной ошибки и самодокументироемости, чем реальная защита от Васи. Также как и pure.

Цитата applegame @ 12.11.15, 10:52

Цитата MyNameIsIgor @ 12.11.15, 10:40

Что такое "честно" иммутабельный по определению?

"Честно" иммутабельный - это который действительно не меняет свое внутреннее состояние, а не делает вид, что не меняет, а на самом деле меняет.

Счётчик ссылок не внутренне состояние объекта, и shared_ptr --- не сам (иммутабельный) объект. Счётчик придётся изменять потокобезопасным способом, но операции над самим объектом не требуют синхронизации, в чём проблема?

Цитата korvin @ 12.11.15, 20:54

Счётчик ссылок не внутренне состояние объекта, и shared_ptr --- не сам (иммутабельный) объект. Счётчик придётся изменять потокобезопасным способом, но операции над самим объектом не требуют синхронизации, в чём проблема?

Это уже обсуждалось выше, не хочу повторять. И да, проблем нет.

applegame, я вот тебе не до конца понимаю. Мешает отсутствие GC иммутабельности и работе с иммутабельными данными из разных потоков или нет?

Цитата D_KEY @ 13.11.15, 09:54

applegame, я вот тебе не до конца понимаю. Мешает отсутствие GC иммутабельности и работе с иммутабельными данными из разных потоков или нет?

Да, мешает в некоторой степени.
Проблема во времени жизни иммутабельных данных. В случае наличия GC собственником является GC, который и уничтожает эти данные, когда доступ к ним из кода теряется. В случае отсутствия GC приходится применять замены вроде shared_ptr, который сводит преимущества иммутабельности, а именно отсутствие необходимости в синхронизации, на нет.

Кроме того shared_ptr сам по себе - еще то говнецо, хуже него только голый указатель. shared_ptr нужно избегать всеми силами и заменять везде, где только возможо на unique_ptr. Что в вышеупомянутом случае невозможно.
Чем он так говнист? Это то, что я вспомнил из личного опыта использования boost::asio + shared_ptr.

1. shared_ptr не умеет обрабатывать циклические ссылки, а значит их обработка ложится на плечи программиста - weak_ptr. То есть даже применив shared_ptr все равно нужно контролировать время жизни объекта.
2. Так как shared_ptr не является частью языка, то при использовании сторонних библиотек не умеющих с ним работать, приходится вытаскивать из shared_ptr непосредственно сам объект, что небезопасно.
3. Сам shared_ptr нифига не потокобезопасен. Опасно обращаться из разных потоков к одному и тому же объекту shared_ptr без синхронизации.
4. Использование указателя на объект завернутого в shared_ptr становится небезопасным везде, в том числе внутри функций-мемберов этого объекта: Никому и нокогда нельзя отдавать голый this, даже если вам кажется, что объект должен жить к моменту использования этого указателя. Лучше перекреститесь и добавьте оверхеда заверните this в shared_ptr и не забудьте про злотрахучий enable_shared_from_this, а то будете долго ломать голову: чего это оно валится на пустом месте?
Плохо:

struct Foo {
    int a;
    void foo() {
        bar([&]{ // опасносте!!! к моменту вызова лямбды объект может быть уже похерен
            cout << a;  
        });
    }
};

Карашо:

struct Foo : enable_shared_from_this<Foo> {
    int a;
    void foo() {
        auto self = shared_from_this();
        bar([=]{
            cout << self->a;    
        });
    }
};

Сообщение отредактировано: applegame - 13.11.15, 11:56

Цитата applegame @ 13.11.15, 11:39

В случае отсутствия GC приходится применять замены вроде shared_ptr, который сводит преимущества иммутабельности, а именно отсутствие необходимости в синхронизации, на нет.

Вот именно это я и не понимаю... Каким образом?

Цитата

shared_ptr нужно избегать всеми силами и заменять везде, где только возможо на unique_ptr.

Скорее не нужно использовать shared_ptr там, где можно обойтись unique_ptr.

Цитата

Что в вышеупомянутом случае невозможно.

Ну это вопрос спорный. Если организовывать пайпы между тредами, т.е. один объект в один момент времени обрабатывает только какой-то один воркер, то передачи владения вполне достаточно. Кроме того, этот способ, как правило, еще и наиболее эффективен в плане организации многопоточной обработки.

Цитата

shared_ptr не умеет обрабатывать циклические ссылки, а значит их обработка ложится на плечи программиста - weak_ptr. То есть даже применив shared_ptr все равно нужно контролировать время жизни объекта.

Ну так если ты отказался от GC, естественно, нужно

Цитата

Так как shared_ptr не является частью языка, то при использовании сторонних библиотек не умеющих с ним работать, приходится вытаскивать из shared_ptr непосредственно сам объект, что небезопасно.

Что в этом такого небезопасного?

Цитата

Сам shared_ptr нифига не потокобезопасен. Опасно обращаться из разных потоков к одному и тому же объекту shared_ptr без синхронизации.

Ну для него есть атомики в C++. Хотя по мне так из разных потоков его дергать и не нужно.

Цитата

Использование указателя на объект завернутого в shared_ptr становится небезопасным везде, в том числе внутри функций-мемберов этого объекта: Никому и нокогда нельзя отдавать голый this, даже если вам кажется, что объект должен жить к моменту использования этого указателя. Лучше перекреститесь и добавьте оверхеда заверните this в shared_ptr и не забудьте про злотрахучий enable_shared_from_this, а то будете долго ломать голову

Это все тот же вопрос о владении и контроле времени жизни. Да, об этом нужно думать.

Только я так и не понял, при чем тут иммутабельность.

Добавлено 13.11.15, 12:35
applegame, а если в C++ использовать boehm, то насколько это сильно страдабельнее, чем в D?

Сообщение отредактировано: D_KEY - 13.11.15, 12:35

1. std::shared_ptr<> и не разрабатывался для каруселей. Он создавался для автоматического подсчёта владельцев объекта в случаях, когда невыгодно или невозможно наделять каждого из них своей копией оригинала. Естественно, что использование его в ситуациях с циклическими ссылками приведёт к бесконечному времени жизни, и это правильное поведение. Для пользователей объекта, а не владельцев, должен использоваться std::weak_ptr<>. Ничего сложного, нужно просто не косячить с архитектурой.
2. Даже если вытащишь, сторонняя библиотека ничего с ним плохого сделать не должна. Не удалит же она его, если только это не прописано в её контракте. Другое дело, что время жизни теперь нельзя контролировать только лишь смартами, ну так это решаемо.
3. Он потокобезопасен полностью. Его гарантия не распространяется на объект, это да. А ты можешь предложить универсальный механизм обеспечения такой безопасности?
4. И что тут удивительного? Гарантии объекта кончаются, как только с данными объекта начинают работать в обход его интерфейса. std::shared_ptr<> имеет чёткий интерфейс: вся работа с подссыльным объектом – только через его операции. Вытащив из него голый this ты фактически получил пункт 2.

Цитата Qraizer @ 13.11.15, 12:54

Он потокобезопасен полностью

Потокобезопасен подсчёт ссылок. Сам объект shared_ptr таких гарантий не даёт, да они и не нужны.

Цитата D_KEY @ 13.11.15, 12:33

Вот именно это я и не понимаю... Каким образом?

Что именно ты не понимаешь? Указатель на иммутабельный объект можно просто передать, а при использовании shared_ptr будут атомики с барьерами памяти. Я уже писал об этом.

Цитата D_KEY @ 13.11.15, 12:33

Только я так и не понял, при чем тут иммутабельность.

К иммутабельности относился только первый абзац моего ответа. Остальное уже относится скорее к GC vs shared_ptr.

Цитата D_KEY @ 13.11.15, 12:33

applegame, а если в C++ использовать boehm, то насколько это сильно страдабельнее, чем в D?

Если честно, для меня главные преимущества D перед C++: читабельные и мощные шаблоны, UFCS, полноценное CTFE, рефлексия может еще какие-нибудь мелочи забыл. GC просто приятная плюшка без которой можно жить, а местами очень хорошо жить.
Говорят D1 был таким, а потом пришел Александреску и все испортил

Цитата Qraizer @ 13.11.15, 12:54

1. std::shared_ptr<> и не разрабатывался для каруселей. Он создавался для автоматического подсчёта владельцев объекта в случаях, когда невыгодно или невозможно наделять каждого из них своей копией оригинала. Естественно, что использование его в ситуациях с циклическими ссылками приведёт к бесконечному времени жизни, и это правильное поведение. Для пользователей объекта, а не владельцев, должен использоваться std::weak_ptr<>. Ничего сложного, нужно просто не косячить с архитектурой.
2. Даже если вытащишь, сторонняя библиотека ничего с ним плохого сделать не должна. Не удалит же она его, если только это не прописано в её контракте. Другое дело, что время жизни теперь нельзя контролировать только лишь смартами, ну так это решаемо.
3. Он потокобезопасен полностью. Его гарантия не распространяется на объект, это да. А ты можешь предложить универсальный механизм обеспечения такой безопасности?
4. И что тут удивительного? Гарантии объекта кончаются, как только с данными объекта начинают работать в обход его интерфейса. std::shared_ptr<> имеет чёткий интерфейс: вся работа с подссыльным объектом – только через его операции. Вытащив из него голый this ты фактически получил пункт 2.

Ну а что есть в C++ для каруселей? Да и все тобой сказанное известно. Все подводные камни shared_ptr хорошо изучены, описаны и придуманы методы их обхода. Но от этого они не перестают быть подводными камнями. Само наличие подобных комней - это минус.

Цитата applegame @ 13.11.15, 13:41

Указатель на иммутабельный объект можно просто передать, а при использовании shared_ptr будут атомики с барьерами памяти. Я уже писал об этом.

Ну и что? Один раз при передачи в тред ты скопируешь shared_ptr. Я уверен, что для большинства задач это будет абсолютно незаметно.

Цитата

Цитата D_KEY @ 13.11.15, 12:33

Только я так и не понял, при чем тут иммутабельность.

К иммутабельности относился только первый абзац моего ответа.

А там были аргументы?

Цитата

Остальное уже относится скорее к GC vs shared_ptr.

Ну это неинтересно

Цитата D_KEY @ 13.11.15, 13:47

Ну и что? Один раз при передачи в тред ты скопируешь shared_ptr. Я уверен, что для большинства задач это будет абсолютно незаметно.

Для большинства задач вообще не нужны треды и immutable как таковые. А в реальных сложных многопоточных приложениях, треды имеют свойство постоянно обмениваться друг с другом объектами. А в моем реальном приложении они это делают постоянно. Ну и в конце-концов это просто удобнее.

Цитата applegame @ 13.11.15, 17:26

А в реальных сложных многопоточных приложениях, треды имеют свойство постоянно обмениваться друг с другом объектами.

В реальных многопоточных приложениях будет так, как ты сделаешь. Для обмена объектами достаточно unique_ptr и передачи владения.

Добавлено 13.11.15, 17:32

Цитата applegame @ 13.11.15, 17:26

Ну и в конце-концов это просто удобнее.

Возможно. Но это выходит за рамки холивара, т.к. не является объективным критерием.

Цитата D_KEY @ 13.11.15, 17:32

Для обмена объектами достаточно unique_ptr и передачи владения.

К сожалению, зачастую недостаточно. Точнее, зачастую невозможно передать владение.

Сообщение отредактировано: applegame - 13.11.15, 17:53