Насколько я знаю, эту ситуацию постепенно улучшают. В первом случае b всё ещё можно использовать. И value тоже можно будет, если переинициализировать a в той же функции. Либо, в случае с такой POD структурой, можно вообще её деструктурировать в отдельные переменные и потом собрать новую.
С вектором вероятно сложнее. Но если мы заранее знаем новое значение для мувнутого элемента, то тут достаточно std::mem::swap() с локальной переменной. Или даже если не знаем, но для элемента реализован Default.
Я сейчас в дороге с телефона, так что неудобно в подтверждение писать код или искать ссылки, извините.
Ну я же написал: лишние аллокации и indirection. Для каких-то кодбаз кстати даже копирование shared_ptr слишком дорогое, потому что оно атомарное, а это не всем нужно. Поправьте, если я неправ, но разделения аналогичного Rc/Arc в плюсы ещё не завезли.
В 2015 вышел стабильный Rust 1.0. Судя по статье на вики, как минимум в 2012 был релиз 0.2. Мне лень копать, когда точно раст опубликовали. Ну и в целом про конкуренцию немного странный аргумент. У самого раста же тоже не было конкуренции с растом) И affine types уже были на тот момент исследованы в других экспериментальных языках, это не изобретение раста.
через стандартную библиотеку
В том-то и дело, что нет. Я же написал про rvalue references
Как любитель функционального стиля, я скажу да ? Но если серьёзно, то да, тут вы правы, по сути это обычная clobbering мутация (в случае стандартных контейнеров). Но блин, введение мув семантики всё равно же потребовало изменений на уровне языка: как минимум синтаксис для rvalue references (&&). Кто им мешал на уровне языка сделать ещё и проверку как в расте, чтобы нельзя было использовать clobbered объекты? Хотя бы раз, хотя бы от единственного блин footgun защитить программиста? Хотя бы спустя 30 лет развития языка?
И вся эта мув семантика без проблем заменяется умными указателями. С абсолютно понятным и предсказуемым поведением.
В целом согласнен, но с указателями в какой-то момент всё упирается в производительность, а мы же про С++ говорим.
Мув семантика - это костыль, которые прикрутили, потому что народ боится указателей.
Не согласен. Мув семантику прикрутили как оптимизацию. Чтобы можно было создать скажем вектор на стеке, избежать лишней аллокации и double indirection при его использовании, но при этом потом всё равно суметь его мувнуть. Или чтобы внутри вектора можно было эффективно свапать произвольные T, лежащие по значению, а не только скажем указатели и стандартные классы (для которых гипотетически могли написать те же мув костыли, но не публикуя их как часть стандарта).
Надо было просто делать как в расте. Чтобы компилятор знал про moved out состояние и запрещал его использовать. Ну и move by default в расте это очень круто, но в плюсах этого конечно не будет, потому что совместимость
Ну не невалидной, а in unspecified state. Какая разница. Пользоваться без переинициализации ей больше нельзя, но компилятор об этом ничего не скажет. Да, в собственном классе можно написать какой угодно specified мув, но это не отменяет того, что стандартные контейнеры из STL ведут себя так, как я написал выше. И что их использование, что написание своих мувов это один сплошной footgun
Судя по этому треду, BidirectionalIterator в расте выразим, но только по immutably borrowed элементам. Почему его нет в стандартной библиотеке, я не знаю. А по мутабельным элементам нельзя by design, в соответствии с правилами borrow checker'а:
The reason is simply aliasing vs mutability. Iterator is designed so that you can retain references to the elements that it yielded, so that if you can go back and forth you would be able to have multiple references to the same element (aka: aliasing). Now, imagine that the references in question are mutable: you now have multiple mutable references to the same element, BOOM. So, since yielding mutable references is desirable, the Iterator trait has given up aliasing.
Насчёт реализаций Sum. В плюсах нет std::sum(), так что предолагаю, что вы Sum::sum() сравниваете с std::accumulate(). Это не совсем корректно, потому что последняя принимает начальное значение и ней не нужно ничего знать про 0. На расте для такого тоже тривиально пишется единственная реализация на трейтах:
use std::iter::Iterator;
use std::ops::Add;
pub fn accumulate<T, I>(it: I, init: T) -> T
where
T: Add<Output=T>,
I: Iterator<Item=T>
{
it.fold(init, Add::add)
}
Посмотрел исходники sum(), по сути там три реализации (вручную написанных макроса): для интов, для флоатов и для Simd. Отличаются они в основном тем, как задаётся изначальное значение: $zero, 0.0 или Simd::splat(0 as $type). В расте нет неявных приведений типов как в плюсах, так что нельзя везде написать просто 0. Честно, не знаю, почему они не завезли в стандартную библиотеку что-то типа num::traits::Zero и не сделали на трейтах вместо макросов. Не вижу для этого особых преград со стороны языка.
Я не тот, кто поставил минус, но в Си разница более существенная - разные версии функции бинарно несовместимы. А в ассембли из обоих вариантов ассемблится одна и та же бинарная инструкция
Эти квартиры возьмутся не из воздуха, а из налогов тех же самых семей. Но эта идея имеет смысл с точки зрения создания уверенности в заврашнем дне (без "что, если я заболею или меня уволят, а у меня ипотека")
Было бы интересно статью про это, как контролируете потребление памяти и т.п. Не знаю конечно, насколько она оправдана. Может там тот же подход, что и везде. Про space leaks уже много написано
Haskell пробовал, тоже очень нравится. Rust выделяется превосходным тулингом и удобством написания контролируемой императивщины. Я уже в другом комменте написал про Rust с GC:
По сути, это уже почти Haskell, но с тонной синтаксического сахара для ST
Ну и сейчас понял ещё, что без контроля IO. Для кого-то это плюс, для кого-то минус.
Взять и добавить можно. Естественно, из-за borrow checker там позволено меньше мутации, чем в типичных GC языках, но я только за. Проблема таких библиотечных решений в том, что они добавляют очень много синтаксического шума. Условно, Gc<GcCell<T>> вместо T. И то же самое со стандартными умными указателями типа Rc и так далее. Такие типы в раст коде как раз многих отпугивают от языка. Было бы интересно посмотреть, каким был бы раст, если бы все объекты были просто garbage collected T (всё ещё с контролируемой мутабельностью), а RAII не было. По сути, это уже почти Haskell, но с тонной синтаксического сахара для ST
Go по сравнению с C++/Rust нужен для быстрого изучения, единообразного кода, быстрой компиляции и отсутствия заморочек с владением памятью. Создатели довольно неплохо описали, какие проблемы C++ они пытались решить. Я б сказал, это у них получилось.
Но, как я написал в другом комменте, в Rust гораздо сильнее типы и он мне больше нравится. Ради них приходится просто мириться с лишними заморочками с владением. Я пишу не настолько низкоуровневые вещи, чтобы они реально требовались и наличие GC/рантайма было проблемой
> nil в 2023 > нет sum types > нет first-class tuples > нет контроля мутабельности > гонки горутин > этот код возвращает err в рантайме, а не ошибку компиляции:
var num int
fmt.Print("Enter an int: ")
_, err := fmt.Scanln(num) // Тут должно быть &num
if err != nil {
fmt.Println("Error: ", err)
} else {
fmt.Println("You've entered: ", num)
}
Язык вроде с типами, но с очень слабыми. Как бы я хотел Rust, но со сборкой мусора...
Понимаю конечно, что суть статьи в демонстрации способностей ChatGPT и задание могло быть любым... Но зачем покрывать тестами геттеры DTOшки? И в названии кликбейт получается. Это явно не задача для "Middle разработчика".
Одобряю редизайн. Я себе какое-то время назад установил Redirector специально чтобы вместо десктопной версии википедии открывалась мобильная. В ней тоже уменьшена плотность и ширина контента и убрано боковое меню
Поправочка, valid but unspecified state ? Люблю плюсы, столько разных слов на un
Насколько я знаю, эту ситуацию постепенно улучшают. В первом случае
bвсё ещё можно использовать. Иvalueтоже можно будет, если переинициализироватьaв той же функции. Либо, в случае с такой POD структурой, можно вообще её деструктурировать в отдельные переменные и потом собрать новую.С вектором вероятно сложнее. Но если мы заранее знаем новое значение для мувнутого элемента, то тут достаточно
std::mem::swap()с локальной переменной. Или даже если не знаем, но для элемента реализованDefault.Я сейчас в дороге с телефона, так что неудобно в подтверждение писать код или искать ссылки, извините.
Ну я же написал: лишние аллокации и indirection. Для каких-то кодбаз кстати даже копирование shared_ptr слишком дорогое, потому что оно атомарное, а это не всем нужно. Поправьте, если я неправ, но разделения аналогичного Rc/Arc в плюсы ещё не завезли.
В 2015 вышел стабильный Rust 1.0. Судя по статье на вики, как минимум в 2012 был релиз 0.2. Мне лень копать, когда точно раст опубликовали. Ну и в целом про конкуренцию немного странный аргумент. У самого раста же тоже не было конкуренции с растом) И affine types уже были на тот момент исследованы в других экспериментальных языках, это не изобретение раста.
В том-то и дело, что нет. Я же написал про rvalue references
Как любитель функционального стиля, я скажу да ? Но если серьёзно, то да, тут вы правы, по сути это обычная clobbering мутация (в случае стандартных контейнеров). Но блин, введение мув семантики всё равно же потребовало изменений на уровне языка: как минимум синтаксис для rvalue references (&&). Кто им мешал на уровне языка сделать ещё и проверку как в расте, чтобы нельзя было использовать clobbered объекты? Хотя бы раз, хотя бы от единственного блин footgun защитить программиста? Хотя бы спустя 30 лет развития языка?
В целом согласнен, но с указателями в какой-то момент всё упирается в производительность, а мы же про С++ говорим.
Не согласен. Мув семантику прикрутили как оптимизацию. Чтобы можно было создать скажем вектор на стеке, избежать лишней аллокации и double indirection при его использовании, но при этом потом всё равно суметь его мувнуть. Или чтобы внутри вектора можно было эффективно свапать произвольные T, лежащие по значению, а не только скажем указатели и стандартные классы (для которых гипотетически могли написать те же мув костыли, но не публикуя их как часть стандарта).
Надо было просто делать как в расте. Чтобы компилятор знал про moved out состояние и запрещал его использовать. Ну и move by default в расте это очень круто, но в плюсах этого конечно не будет, потому что совместимость
Ну не невалидной, а in unspecified state. Какая разница. Пользоваться без переинициализации ей больше нельзя, но компилятор об этом ничего не скажет. Да, в собственном классе можно написать какой угодно specified мув, но это не отменяет того, что стандартные контейнеры из STL ведут себя так, как я написал выше. И что их использование, что написание своих мувов это один сплошной footgun
Судя по этому треду,
BidirectionalIteratorв расте выразим, но только по immutably borrowed элементам. Почему его нет в стандартной библиотеке, я не знаю. А по мутабельным элементам нельзя by design, в соответствии с правилами borrow checker'а:Насчёт реализаций
Sum. В плюсах нетstd::sum(), так что предолагаю, что выSum::sum()сравниваете сstd::accumulate(). Это не совсем корректно, потому что последняя принимает начальное значение и ней не нужно ничего знать про 0. На расте для такого тоже тривиально пишется единственная реализация на трейтах:Посмотрел исходники
sum(), по сути там три реализации (вручную написанных макроса): для интов, для флоатов и дляSimd. Отличаются они в основном тем, как задаётся изначальное значение:$zero,0.0илиSimd::splat(0 as $type). В расте нет неявных приведений типов как в плюсах, так что нельзя везде написать просто0. Честно, не знаю, почему они не завезли в стандартную библиотеку что-то типа num::traits::Zero и не сделали на трейтах вместо макросов. Не вижу для этого особых преград со стороны языка.Я не тот, кто поставил минус, но в Си разница более существенная - разные версии функции бинарно несовместимы. А в ассембли из обоих вариантов ассемблится одна и та же бинарная инструкция
Эффект первой строки?) В С нет namespace std
В треде на hackernews есть пояснения
Эти квартиры возьмутся не из воздуха, а из налогов тех же самых семей. Но эта идея имеет смысл с точки зрения создания уверенности в заврашнем дне (без "что, если я заболею или меня уволят, а у меня ипотека")
Было бы интересно статью про это, как контролируете потребление памяти и т.п. Не знаю конечно, насколько она оправдана. Может там тот же подход, что и везде. Про space leaks уже много написано
Проблема не в том, что введёт пользователь. Scanln возвращает err всегда. Сразу же, не дожидаясь ввода. Можете запустить на Go Playground и посмотреть
Haskell пробовал, тоже очень нравится. Rust выделяется превосходным тулингом и удобством написания контролируемой императивщины. Я уже в другом комменте написал про Rust с GC:
Ну и сейчас понял ещё, что без контроля IO. Для кого-то это плюс, для кого-то минус.
Взять и добавить можно. Естественно, из-за borrow checker там позволено меньше мутации, чем в типичных GC языках, но я только за. Проблема таких библиотечных решений в том, что они добавляют очень много синтаксического шума. Условно,
Gc<GcCell<T>>вместоT. И то же самое со стандартными умными указателями типаRcи так далее. Такие типы в раст коде как раз многих отпугивают от языка. Было бы интересно посмотреть, каким был бы раст, если бы все объекты были просто garbage collectedT(всё ещё с контролируемой мутабельностью), а RAII не было. По сути, это уже почти Haskell, но с тонной синтаксического сахара для STGo по сравнению с C++/Rust нужен для быстрого изучения, единообразного кода, быстрой компиляции и отсутствия заморочек с владением памятью. Создатели довольно неплохо описали, какие проблемы C++ они пытались решить. Я б сказал, это у них получилось.
Но, как я написал в другом комменте, в Rust гораздо сильнее типы и он мне больше нравится. Ради них приходится просто мириться с лишними заморочками с владением. Я пишу не настолько низкоуровневые вещи, чтобы они реально требовались и наличие GC/рантайма было проблемой
> nil в 2023
> нет sum types
> нет first-class tuples
> нет контроля мутабельности
> гонки горутин
> этот код возвращает err в рантайме, а не ошибку компиляции:
Язык вроде с типами, но с очень слабыми. Как бы я хотел Rust, но со сборкой мусора...
Понимаю конечно, что суть статьи в демонстрации способностей ChatGPT и задание могло быть любым... Но зачем покрывать тестами геттеры DTOшки? И в названии кликбейт получается. Это явно не задача для "Middle разработчика".
Одобряю редизайн. Я себе какое-то время назад установил Redirector специально чтобы вместо десктопной версии википедии открывалась мобильная. В ней тоже уменьшена плотность и ширина контента и убрано боковое меню