Rust vs Чистейший Си , и еще си шарп вдогоночку

ADD: Оставлю тут линк для пользы дела "Модели дженериков и метапрограммирования: Go, Rust, Swift, D и другие" (оригинал тут).

Цитата D_KEY @ 31.08.19, 13:45

А вот тут врут.

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

Цитата OpenGL @ 01.09.19, 12:05

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

Так это же фича. Утиность шаблонов. Типобезопасность тут при чем? Если тип не подходит под шаблон, то ничего не скомпилируется, т.е. все безопасно.

Добавлено 01.09.19, 12:29

Цитата JoeUser @ 31.08.19, 19:28

Наличие конструкторов только копирования до С++11 требовало определенных костылей, чтобы не было оверхеда. В Расте наоборот - перенос наоборот по-умолчанию, для создания копии сущности нужно писать дополнительно код.

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

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

Цитата D_KEY @ 01.09.19, 12:24

Так это же фича.

Я знаю, что это фича. Может быть тот, кто говорил эту фразу про безопасность это считает багом

Цитата D_KEY @ 01.09.19, 12:24

Каких костылей?

Ну вот, допустим, ты пишешь свой класс строки и хочешь, чтобы в коде наподобие:

MySuperPuperString str = "Foo" + other_string + "bar" + another_string;

было как можно меньше созданий временных объектов и лишних копирований. До С++11 эта задача решалась через жопу. Непонятно правда, что это меняет и причём тут противоречие с нулевой стоимостью, но, подозреваю, JoeUser всё-таки об этом

Цитата D_KEY @ 01.09.19, 12:24

В раст по умолчанию это для переменных так работает, поля структурок он же по значению хранит?

Не так! Все зависит от типа, и какой из типажей он имеет - Copy или Drop.

Цитата D_KEY @ 01.09.19, 12:24

Утиность шаблонов. Типобезопасность тут при чем?

Потому, что "утиность" присутствует в термине "Утиная типизация". Подстановка не того типа - ошибка типизации.
И до С++11 обуздать прожорливость SFINAE было непросто, в С++11 пришла радость в виде std::enable_if

Цитата JoeUser @ 01.09.19, 14:46

в С++11 пришла радость в виде std::enable_if

это не радость, а костыль, и он пришел до C++11 и назывался boost::enable_if

Цитата applegame @ 01.09.19, 16:26

boost::enable_if

Насчет буста ...

- Скажите, что на ваш взгляд хуже: невежество, безграмотность или безразличие?
- Не знал, ни знаю, и мне пох!

Радость, ирония - просто игра слов.

Цитата JoeUser @ 01.09.19, 14:46

Не так! Все зависит от типа, и какой из типажей он имеет - Copy или Drop.

С типажом Copy

fn main() {
  let a:u32 = 1;
  let b:u32 = a;
  println!("{}",a);
}

Все норм, выведет: 1

Без типажа Copy

struct Struct {
  f: u32    
}
 
fn main() {
  let  a:Struct = Struct{f:1};
  let _b:Struct = a;
  println!("{}",a.f);
}

Получаем ошибку: error[E0382]: use of moved value: `a.f`

Цитата JoeUser @ 01.09.19, 16:43

С типажом Copy

Цитата JoeUser @ 01.09.19, 16:43

Без типажа Copy

Код выглядит очень похоже. В чём прелесть такой разной реакции?

Цитата amk @ 01.09.19, 17:22

В чём прелесть такой разной реакции?

Тонкий вброс, однако

Цитата amk @ 01.09.19, 17:22

В чём прелесть такой разной реакции?

В эффективности. Типаж Copy по умолчанию имеют а-ля POD:

• целочисленные типы
• логический тип
• с плавающей точкой
• кортежи, если они содержат исключительно первые три типа

Просто их выгодно по затратам/скорости размещать на стеке.
А вот все остальное - немного иначе. Управляющие элементы типа размещаются на стеке, а непосредственно сами данные - в куче. И присвоение (а не клонирование) перемещает только управляющие данные. То, что в куче - остается неизменным. По-умолчанию это пресловутая "нулевая стоимость", когда производится только необходимый минимум действий.

Да и подход у Раста специфический (если тот звон, который я слышал, правильный - то звон несколько Хаскелевский) - переменная не "имеет значение", а переменная "владеет значением". Это вносит определенный порядок. Хотя, соглашусь, изначальную реализацию POD/неPOD надо помнить. А то как в Америке некогда "вход только для белых".

ADD: Хоть и тема о Чистейшем Си, для плюсанутых уточню: термин "типаж" отчасти совсем немножко близок в С++ к его кухне #include <type_traits>

Цитата JoeUser @ 01.09.19, 18:04

Управляющие элементы типа размещаются на стеке, а непосредственно сами данные - в куче.

Это частный случай. В общем случае это совершенно не обязательно, достаточно чтобы сущность держала какой-либо ресурс. В твоём примере это может быть, например, хендл файла.

Добавлено 01.09.19, 18:19

Цитата JoeUser @ 01.09.19, 18:04

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

О, кстати, вот тебе и "нулевая стоимость". Если у тебя объект, для перемещения которого достаточно копировать только часть полей, то в С++ ты просто напишешь соответствующим образом конструктор перемещения, а вот раст честно переместит всё

Цитата OpenGL @ 01.09.19, 18:17

Это частный случай. В общем случае это совершенно не обязательно, достаточно чтобы сущность держала какой-либо ресурс. В твоём примере это может быть, например, хендл файла.

Мастер, тебе виднее! Я пока излагаю официальную документацию.
Однако, если хэндл файла описывается POD - противоречия нет совсем, ибо хендл "держит" только целое!
А вот если сущность держит сложный набор описателей (допустим для обслуживания вектора), тут уж другой колинкор. Данные строго в куче!

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

Цитата OpenGL @ 01.09.19, 18:17

Если у тебя объект

Мастер, не убивай мне моск!

Здесь тема о Расте и Чистейшем Си!

Основные аксиомы костыльно-ориентированного программирования помню:

• 1. Костылирование
• 2. Инкостыляция
• 3. Поликостылизм

Где,

1) Костылирование — это создание костылей, позволяющее описать новый костыль на основе уже существующего с частично или полностью заимствующимися ошибками. Костыль, от которого производится наследование, называется базовым, родительским или суперкостылем. Новый костыль — потомком, наследником или производным.
2) Инкостыляция — это свойство костылей, позволяющее объединить фиксы и заплатки, работающие с ними в классе, и скрыть детали реализации от понимания.
3) Поликостылизм — это свойство разработчиков использовать костыли с одинаковым интерфейсом без информации о типе и внутренней структуре костыля.

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

Цитата JoeUser @ 01.09.19, 18:35

Если структура, у которой часть полей при перемещении учитывать не нужно - меняй дизайн

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