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

Цитата applegame @ 12.11.15, 11:30

Цитата D_KEY @ 12.11.15, 10:56

Там же константные поля. Так что с сопротивлением

А что будет если владелец уничтожит объект? Например первый поток закончит работу раньше второго?

Так там же shared_ptr.

Добавлено 12.11.15, 12:19

Цитата applegame @ 12.11.15, 11:42

Но если вот этот тип T для меня сделал Вася, то я бы очень хотел, чтобы его const функции были бы на самом деле const. А то я создам immutable глобальную переменную типа T, компилятор запихнет ее в data-сегмент, а тут выяснится, что const-функция оказалась не const и все дело падает в ран-тайме. Нехорошо, Вася. Нехорошо.

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

Цитата MyNameIsIgor @ 12.11.15, 12:06

Да любой функциональный язык может. Там все сущности иммутабельны, но почему-то не расположены в памяти с защитой от записи. Интересно, почему?

Потому что у всех изъяли, как вы выразились, кухонные ножи. А в каком-нибудь Haskell изъяли также вилки, ложки и иголки.

Цитата MyNameIsIgor @ 12.11.15, 12:06

Проблема в том, что если хочется приблизиться к "железу", то чем-то надо жертвовать. Я не понимаю обеспечение безопасности с помощью изъятия у всех кухонных ножей.

Я тоже этого не понимаю. В итоге имеем монстра D, в который все пичкают и пичкают всякие ненужные хрени вроде якобы безопасного RC. Правильно ругался на Александреску один из адептов D: прежде чем думать о безопасном аж жуть RC, сделайте обычный не совсем безопасный RC а-ля шаред_птр, и не совсем безопасные контейнеры с аллокаторами. А они вместо этого дружно ломают голову над тем как впихнуть невпихуемое.

Цитата D_KEY @ 12.11.15, 12:16

Так там же shared_ptr.

Во второй поток ты передал ссылку на сам объект а не shared_ptr.

Цитата D_KEY @ 12.11.15, 09:39

struct A
...
// если не являемся владельцем
void thread_fun(const A & obj)
{
    // читаем сколько влезет из obj без синхронизации
}

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

Цитата applegame @ 12.11.15, 12:23

Во второй поток ты передал ссылку на сам объект а не shared_ptr.

Сорри, я неправильно объяснил. Это не второй поток. Или все потоки работают с shared_ptr или есть отдельные воркеры, которые не являются владельцами и просто читают объект по ссылке и есть какой-то агрегатор, который владеет объектом и ожидает завершения воркеров.

Сообщение отредактировано: D_KEY - 12.11.15, 13:05

Цитата applegame @ 12.11.15, 12:04

Я понимаю, что иммутабельность через битовую неизменность - это суррогат, но можете ли вы предложить что-нибудь лучше?

Константные объекты вместо константных ссылок на них, не? А честная она там или нет, это никому не интересно. Если даже и есть внутри mutable-поля, это проблемы сугубо автора класса и компилятора.

Цитата Qraizer @ 12.11.15, 12:55

Константные объекты вместо константных ссылок на них, не?

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

Цитата Qraizer @ 12.11.15, 12:55

А честная она там или нет, это никому не интересно. Если даже и есть внутри mutable-поля, это проблемы сугубо автора класса и компилятора.

А если такой объект расположен в ПЗУ? Компилятор же не в состоянии распознать честная иммутабельность или нет? Написано immutable, значит immutable.

Зачем копировать? Создал константный объект и радуешься. Хочешь – копируй, хочешь – ссылайся.
Если объект расположен в ПЗУ, он по определению не может быть создан конструктором, потому что тот предполагает модификацию полей объекта для придания ему некоего состояния. В таком случае он должен быть туда помещён уже сконструированным, и для работы с ним достаточно ссылки.

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

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

Это же был пример, т.к. вы говорили про "маленькие иммутабельные объекты"
Вариантов может быть много.

Добавлено 12.11.15, 14:19
Во, кстати, а какой GC сейчас использует D? Если как и раньше BoehmGC, то это fail.

Цитата Qraizer @ 12.11.15, 13:52

Зачем копировать? Создал константный объект и радуешься. Хочешь – копируй, хочешь – ссылайся.

Сосбственно об этом я и говорил.

Цитата Qraizer @ 12.11.15, 13:52

Если объект расположен в ПЗУ, он по определению не может быть создан конструктором, потому что тот предполагает модификацию полей объекта для придания ему некоего состояния. В таком случае он должен быть туда помещён уже сконструированным, и для работы с ним достаточно ссылки.

Отлично. А теперь ты по этой ссылке вызываешь некий const-метод этого класса, а он оказывается не совсем const и пытается модифицировать свои поля, которые находятся в области недоступной для записи.

Добавлено 12.11.15, 14:38

Цитата MyNameIsIgor @ 12.11.15, 14:14

Во, кстати, а какой GC сейчас использует D? Если как и раньше BoehmGC, то это fail.

Ага, он самый, родной. В теории может течь, но на практике не течет. По крайней мере на 64-битном линупсе.

Цитата applegame @ 12.11.15, 14:22

Ага, он самый, родной. В теории может течь, но на практике не течет. По крайней мере на 64-битном линупсе.

Да он не должен течь. Просто консервативный, может что угодно за указатель посчитать и не почистить. С другой стороны он должен меньше ресурсов требовать, тегирование всякое ему не нужно. Но получается, что я и на C++ могу получить GC того же качества, что в D

Сообщение отредактировано: MyNameIsIgor - 12.11.15, 14:41

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

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

Поэтому и может течь. Теоретически. Точнее даже не течь, а просто зажимать память до некоторого момента.

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

Но получается, что я и на C++ могу получить GC того же качества, что в D

Конечно. Собственно, ЕМНИП, BoehmGC изначально и был придуман для C/C++.

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

Цитата applegame @ 12.11.15, 14:44

ЕМНИП, BoehmGC изначально и был придуман для C/C++

Именно так.

Цитата applegame @ 11.11.15, 17:14

Вот еще впечатление от Rust после С++/D - Rust impressions from a C++/D programmer

Читал, местами интересно. С чем-то согласен (например, Display/Debug), а что-то наоборот кажется преимуществом. Ну и кое-что "когда-то допилят/исправят".

Цитата applegame @ 12.11.15, 14:22

Цитата Qraizer @ 12.11.15, 13:52

Если объект расположен в ПЗУ, он по определению не может быть создан конструктором, потому что тот предполагает модификацию полей объекта для придания ему некоего состояния. В таком случае он должен быть туда помещён уже сконструированным, и для работы с ним достаточно ссылки.

Отлично. А теперь ты по этой ссылке вызываешь некий const-метод этого класса, а он оказывается не совсем const и пытается модифицировать свои поля, которые находятся в области недоступной для записи.

Хорошо, давай развёрнуто.
Константный объект является константным. Константный метод не может в своём объекте что-либо изменить, компиляция не пройдёт. Но он может снять константность const_cast<> и менять что угодно. Прав ли он? Ответ двоякий. Стандарт языка описывает корректность сей конструкции для объектов, не создававшихся константными. Т.е. для тех, которые обычные, но константность им была придана дополнительными мерами. Например, посредством передачи по константной ссылке в функцию, или, как вот тут, добавлением const к this контрактом метода. Итп. Когда ты передаёшь обычный объект по константной ссылке или указателю, ты как раз получаешь вон то самое константное, которое не совсем константное. Однако если объект был создан уже константным, то в этом случае const_cast<>, снимающий с него константность, по Стандарту (точнее, не конкретно const_cast<>, а последующая модификация объекта) приводит к неопределённому поведению, откуда следует всё остальное нехорошее. Потому я и спросил, поможет ли тебе создание изначально константных объектов вместо искусственно навешанных на них ярлыков const.
Прикол в том, что автор класса реально не знает, какой this ему пришёл в метод, константный искусственно или от рождения. Поэтому const_cast<> внутри const-методов – это линейкой по рукам и переквалификация в инженера-программиста без категории, кроме как автор гарантированно смог избежать UB. Совсем другое дело, если некие поля, типа тех же счётчиков в shared_ptr<>, не являются частью состояния объектов. Или как я люблю делать CRITICAL_SECTION в качестве полей объектов. В этом случае такие поля выносятся за пределы контрактов константности посредством mutable, и мало того, что автору класса уже по барабану, каким именно образом константен объект, так и обеспечение возможности модификации этих полей ложится на плечи компилятора. Ну ещё и и линкера в ряде случаев.

Добавлено 12.11.15, 15:19
Опять же можно надавить на линкер и заставить его-таки сделать то, что он по-хорошему в упор делать отказывается. Но тогда модификация mutable-полей, вызывающая в итоге UB, не должна ИМХО никого удивлять, разве нет?

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

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

По моему, это не сильно отличается, скажем, от гарантий в плане того, что функция openFile может делать совсем другое.

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

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

По моему, это не сильно отличается, скажем, от гарантий в плане того, что функция openFile может делать совсем другое.

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