Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[18.226.165.131] |
|
Страницы: (7) « Первая ... 4 5 [6] 7 все ( Перейти к последнему сообщению ) |
Сообщ.
#76
,
|
|
|
ADD: Оставлю тут линк для пользы дела "Модели дженериков и метапрограммирования: Go, Rust, Swift, D и другие" (оригинал тут).
|
Сообщ.
#77
,
|
|
|
Смотря что тут под типобезопасностью понимается. Возможно, тут имеется ввиду, что в плюсах у тебя компилятор съест всё, что подходит под шаблон, неважно, нужный это класс или у него случайно есть методы, которые использует шаблон функции. В расте же у тебя шаблонная функция примет только тот тип, который реализует нужный трейт. |
Сообщ.
#78
,
|
|
|
Цитата OpenGL @ Возможно, тут имеется ввиду, что в плюсах у тебя компилятор съест всё, что подходит под шаблон, неважно, нужный это класс или у него случайно есть методы, которые использует шаблон функции. Так это же фича. Утиность шаблонов. Типобезопасность тут при чем? Если тип не подходит под шаблон, то ничего не скомпилируется, т.е. все безопасно. Добавлено Цитата JoeUser @ Наличие конструкторов только копирования до С++11 требовало определенных костылей, чтобы не было оверхеда. В Расте наоборот - перенос наоборот по-умолчанию, для создания копии сущности нужно писать дополнительно код. Каких костылей? Ты про CoW? Это не костыль, а паттерн, который используется много где и совершенно не противоречит семантики перемещения. В раст по умолчанию это для переменных так работает, поля структурок он же по значению хранит? |
Сообщ.
#79
,
|
|
|
Цитата D_KEY @ Так это же фича. Я знаю, что это фича. Может быть тот, кто говорил эту фразу про безопасность это считает багом Цитата D_KEY @ Каких костылей? Ну вот, допустим, ты пишешь свой класс строки и хочешь, чтобы в коде наподобие: MySuperPuperString str = "Foo" + other_string + "bar" + another_string; было как можно меньше созданий временных объектов и лишних копирований. До С++11 эта задача решалась через жопу. Непонятно правда, что это меняет и причём тут противоречие с нулевой стоимостью, но, подозреваю, JoeUser всё-таки об этом |
Сообщ.
#80
,
|
|
|
Цитата D_KEY @ В раст по умолчанию это для переменных так работает, поля структурок он же по значению хранит? Не так! Все зависит от типа, и какой из типажей он имеет - Copy или Drop. Цитата D_KEY @ Утиность шаблонов. Типобезопасность тут при чем? Потому, что "утиность" присутствует в термине "Утиная типизация". Подстановка не того типа - ошибка типизации. И до С++11 обуздать прожорливость SFINAE было непросто, в С++11 пришла радость в виде std::enable_if |
Сообщ.
#81
,
|
|
|
Цитата JoeUser @ это не радость, а костыль, и он пришел до C++11 и назывался boost::enable_if в С++11 пришла радость в виде std::enable_if |
Сообщ.
#82
,
|
|
|
Цитата applegame @ boost::enable_if Насчет буста ... - Скажите, что на ваш взгляд хуже: невежество, безграмотность или безразличие? - Не знал, ни знаю, и мне пох! Радость, ирония - просто игра слов. Цитата JoeUser @ Не так! Все зависит от типа, и какой из типажей он имеет - 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` |
Сообщ.
#83
,
|
|
|
Цитата JoeUser @ С типажом Copy Цитата JoeUser @ Код выглядит очень похоже. В чём прелесть такой разной реакции? Без типажа Copy |
Сообщ.
#84
,
|
|
|
Цитата amk @ В чём прелесть такой разной реакции? Тонкий вброс, однако |
Сообщ.
#85
,
|
|
|
Цитата amk @ В чём прелесть такой разной реакции? В эффективности. Типаж Copy по умолчанию имеют а-ля POD: Просто их выгодно по затратам/скорости размещать на стеке. А вот все остальное - немного иначе. Управляющие элементы типа размещаются на стеке, а непосредственно сами данные - в куче. И присвоение (а не клонирование) перемещает только управляющие данные. То, что в куче - остается неизменным. По-умолчанию это пресловутая "нулевая стоимость", когда производится только необходимый минимум действий. Да и подход у Раста специфический (если тот звон, который я слышал, правильный - то звон несколько Хаскелевский) - переменная не "имеет значение", а переменная "владеет значением". Это вносит определенный порядок. Хотя, соглашусь, изначальную реализацию POD/неPOD надо помнить. А то как в Америке некогда "вход только для белых". ADD: Хоть и тема о Чистейшем Си, для плюсанутых уточню: термин "типаж" отчасти совсем немножко близок в С++ к его кухне #include <type_traits> |
Сообщ.
#86
,
|
|
|
Цитата JoeUser @ Управляющие элементы типа размещаются на стеке, а непосредственно сами данные - в куче. Это частный случай. В общем случае это совершенно не обязательно, достаточно чтобы сущность держала какой-либо ресурс. В твоём примере это может быть, например, хендл файла. Добавлено Цитата JoeUser @ По-умолчанию это пресловутая "нулевая стоимость", когда производится только необходимый минимум действий. О, кстати, вот тебе и "нулевая стоимость". Если у тебя объект, для перемещения которого достаточно копировать только часть полей, то в С++ ты просто напишешь соответствующим образом конструктор перемещения, а вот раст честно переместит всё |
Сообщ.
#87
,
|
|
|
Цитата OpenGL @ Это частный случай. В общем случае это совершенно не обязательно, достаточно чтобы сущность держала какой-либо ресурс. В твоём примере это может быть, например, хендл файла. Мастер, тебе виднее! Я пока излагаю официальную документацию. Однако, если хэндл файла описывается POD - противоречия нет совсем, ибо хендл "держит" только целое! А вот если сущность держит сложный набор описателей (допустим для обслуживания вектора), тут уж другой колинкор. Данные строго в куче! |
Сообщ.
#88
,
|
|
|
Вообще, для того, чтобы понять, зачем было сделано именно так, достаточно понять основную идею - авторы языка хотели, чтобы любая сущность могла перемещаться простым memmove, и чтобы это работало как надо во всех случаях, нужно запрещать использовать старый объект.
|
Сообщ.
#89
,
|
|
|
Цитата OpenGL @ Если у тебя объект Мастер, не убивай мне моск! Здесь тема о Расте и Чистейшем Си! Основные аксиомы костыльно-ориентированного программирования помню: Где, 1) Костылирование — это создание костылей, позволяющее описать новый костыль на основе уже существующего с частично или полностью заимствующимися ошибками. Костыль, от которого производится наследование, называется базовым, родительским или суперкостылем. Новый костыль — потомком, наследником или производным. 2) Инкостыляция — это свойство костылей, позволяющее объединить фиксы и заплатки, работающие с ними в классе, и скрыть детали реализации от понимания. 3) Поликостылизм — это свойство разработчиков использовать костыли с одинаковым интерфейсом без информации о типе и внутренней структуре костыля. Если структура, у которой часть полей при перемещении учитывать не нужно - меняй дизайн! В таргете часть полей будут неинициализированы. Меняй сущности обмена, вместо жырной структуры - гоняй срезы массивов. Это будет по фэншую! Ящетаю. |
Сообщ.
#90
,
|
|
|
Цитата JoeUser @ Если структура, у которой часть полей при перемещении учитывать не нужно - меняй дизайн Зачем? Ну вот есть поля, которые используются только когда объект находится в определённом состоянии и инициализируются когда объект в него входит. В конструкторе я их проинициализирую, конечно, и вовсе не факт, что из полей старого объекта. |