Wrzucam na githuba moje mizerne próby z Rustem w ramach AoC, więc jeśli ktoś chciałby się popastwić i wyjaśnić czemu to wszystko jest źle, to zapraszam: https://github.com/Pharisaeus/AoC2021/tree/master/src :)
edit: dla jasności nie przerobiłem nawet żadnego kursu Rusta, odpalam IntelliJ i pisze "na czuja" :D
Łooo panie, ile kodu. Nawet traity implementujesz. Jest sens implementować traity jak i tak nie potrzebujesz polimorfizmu? (Chyba że potrzebujesz, tylko okiem z komórki rzuciłem). Ja wiem że w OOP się trzecie te interfejsy i klasy czy jest to potrzebne czy nie (wyjątkiem jest chyba tylko Kotlin) ale czy w Ruscie tez jest taka konwencja?
KamilAdam napisał(a):
Łooo panie, ile kodu. Nawet traity implementujesz. Jest sens implementować traity jak i tak nie potrzebujesz polimorfizmu?
Gdzie te implementacje traitów? impl Cośtam { ... } to nie jest implementacja traitu. Implementacja traitu to raczej coś a'la impl TraitName for StructName { ... }.
Ostatnia instrukcja jest niejako "auto return", tzn. wystarczy:
Rust fn part1(commands: &[Command]) -> i32 {
/* ... */
pos * depth
}
Explicit return wykorzystywany jest jedynie w sytuacjach early-exit, wyjść z pętli itd.
Dzięki temu, że pętla for item in items desugaruje się do:
let items = items.into_iter();
while let Some(item) = items.next() {
/* ... */
}
... oraz że istnieje IntoIterator dla &[T], wystarczy np. for command in commands {, bez wprost .iter().
fn part1_fun(commands: &[Command]) -> i32 {
let final_state = commands.iter()
.fold(State1 { pos: 0, depth: 0 }, move_sub1);
return final_state.pos * final_state.depth;
}
=>
#[derive(Default)]
struct State1 {
/* ... */
}
impl State1 {
fn score(self) -> i32 {
/* ... */
}
}
fn part1_fun(commands: &[Command]) -> i32 {
commands
.iter()
.fold(Default::default(), move_sub1)
.score()
}
Zwyczajowo dorzuca się adnotacje tylko do tych typów, z którymi kompilator ma problem - tzn.:
let commands: Vec<Command> = contents.lines()
.map(|line| Command::new(line))
.collect();
=>
let commands: Vec<_> = contents.lines().map(Command::new).collect();
Jeśli istnieje trait pokrywający daną funkcjonalność, to zazwyczaj nie robi się "freestanding" funkcji:
impl Board {
/* ... */
fn clone(&self) -> Board {
/* ... */
}
}
... a implementuje dany trait:
impl Clone for Board {
/* ... */
}
(clippy ma nawet na to linta! :-))
Zwyczajowo settery nazywa się set_foo(), lecz gettery po prostu foo() (https://rust-lang.github.io/api-guidelines/naming.html).
no sentinel values, only ADTs angry doge meme
fn part1(data: &InputData) -> i32 {
/* ... */
for number in data.numbers.iter() {
/* ... */
if boards.is_any_winning() {
return /* ... */;
}
}
return -1;
}
=>
fn part1(data: &InputData) -> Option<u32> {
/* ... */
for number in &data.numbers {
/* ... */
if boards.is_any_winning() {
return Some(/* ... */);
}
}
None
}
struct BinNumber {
value: Vec<i32>,
}
=>
struct BinNumber {
value: Vec<bool>,
}
(to uprości np. negowanie)
Tak ogólnie to fajen - kod wygląda całkiem dobrze, a widzę, że i nawet miejsce na Itertools się znalazło :-)
Patryk27 napisał(a):
- Jeśli istnieje trait pokrywający daną funkcjonalność, to zazwyczaj nie robi się "freestanding" funkcji:
... a implementuje dany trait:impl Board { /* ... */ fn clone(&self) -> Board { /* ... */ } }(clippy ma nawet na to linta! :-))impl Clone for Board { /* ... */ }
Można wstawić #[derive(Clone, Copy, Debug, Eq, PartialEq)] przed struct czy enum i mieć za darmo implementacje różnych traitów, pod warunkiem, że wszystkie pola też mają (rekurencyjnie) implementacje tych traitów. Szczegóły: https://doc.rust-lang.org/rust-by-example/trait/derive.html
P.S. Copy to tylko do bardzo lekkich struktur. Do czegokolwiek nietrywialnego należy użyć Clone. Różnica jest taka, że kopiowanie jest niejawne, automatyczne, a klonowanie jest jawne, więc widać gdzie ponosimy koszt klonowania.
fn clone() mają jakąś własną logikę, ale faktycznie to tylko pass-through do .clone() ich pól.
Copy i Clone jest jeszcze na innym poziomie - Copy jest wyłącznie do kopiowania płaskich wartości, które można skopiować kopiując obszar pamięci jednym ciągiem (czyli przez memcpy). Nie da się zrobić głębokiego Copy schodzącego głębiej poprzez referencje. Zauważ, że Copy to tylko marker, nie ma żadnych metod.
Zwyczajowo dorzuca się adnotacje tylko do tych typów, z którymi kompilator ma problem - tzn.:
let commands: Vec<_> = contents.lines().map(Command::new).collect();
Można użyć collect_vec() i wtedy w ogóle nie musisz podawać typu.
Chciałem dziś zrobić ładnie z .fold() ale kopiowanie boarda po oznaczeniu pola strasznie się ślimaczyło, a nie umiem przekonać borrow-checkera do jakiegoś:
lines.iter()
.fold(board, |board, line| board.mark_line(line));
ale w sytuacji kiedy mark_line nie zwraca kopii Board tylko &Board
edit: Żeby wyjaśnić o co pytam. Można by napisać taki kod:
use itertools::Itertools;
struct Board {
board: Vec<i32>,
}
impl Board {
fn new(size: i32) -> Board {
return Board { board: (0..size).map(|x| 0).collect_vec() };
}
fn mark_field(&self, index: usize) -> Board {
return Board {
board: self.board
.iter()
.enumerate()
.map(|(i, &value)| if i == index { value + 1 } else { value })
.collect_vec()
};
}
}
pub(crate) fn solve() {
let board = (0..10000)
.fold(Board::new(10000), |board, index| board.mark_field(index));
println!("{}", board.board[1]);
}
Czyli za każdym razem kiedy robimy mark_field zwracamy nową planszę. Tylko że jak plansza jest duża to nagle robi sie to bardzo wolne, z oczywistych względów.
I teraz zastanawiałem się, czy można tak zrobić, zeby nasze mark_field zwracało zmodyfikowaną początkową tablicę, a nie tworzyło nową za każdym razem (pytanie co jest "bardziej rustowe" i moze jest jakaś trzecia opcja?). I pisząc tego posta doszedłem do tego, ze mogę zrobić:
fn mark_field(mut self, index: usize) -> Board {
self.board[index]+=1;
return self;
}
Bo mogę przyjąć sobie self a nie &self jako argument.
fold zaciemnia sytuację, bo właśnie sugeruje że dostajesz coś nowego, a tu chcemy po prostu zmodyfikować jeden istniejący obiekt.
(0..size).map(|x| 0).collect_vec() bleh, vec![0, size]
vec![0; size]; przecinek utworzyłby wektor z dwoma elementami ([0, size] vs [0, 0, 0, ...]).
Hmm dość specyficzny język. Moim zdaniem miejscami mocno autystyczny, kiedy np. nie możesz porównać &int z intem i musisz robić jakiś cyrk w stylu &0. Dodatkowo nie wyobrażam sobie pisania w Ruście bez silnego wsparcia IDE, które pokazuje wyniki inferencji typów, szczególnie kiedy nagle po jakimś .iter() czy w jakimś .map() dostajesz &&X.
Swoją drogą, biorąc pod uwagę brak raw-pointerów jako takich (w sensie jakiegoś int* ptr = 0x12345; w C), zastanawiam się, czemu składnia idzie w kierunku pointerów z C (w kontekście & i *) a nie czegoś na wzór referencji.
Swoją drogą, biorąc pod uwagę brak raw-pointerów jako takich
FWIW, istnieją raw pointery:
fn main() {
let ptr = 0x12345 as *const i32;
println!("{}", unsafe { *ptr }); // 99% szansy na segfault
}
a nie czegoś na wzór referencji.
W sensie, że bez ręcznego pisania *? Taki mechanizm już istnieje i nazywa się auto-deref :-)
Shalom napisał(a):
Dodatkowo nie wyobrażam sobie pisania w Ruście bez silnego wsparcia IDE, które pokazuje wyniki inferencji typów, szczególnie kiedy nagle po jakimś .iter() czy w jakimś .map() dostajesz &&X.
To może być przyzwyczajenie javowe - zupełnie niepotrzebne natręctwo do podglądania typów. Podobny problem niektórzy raportują w kotlinie... podczas kiedy całkiem dobrze się pisze z wyłączonymi hintami typów. W haskellu to norma, że typów nie widzisz przez całe długie kawałki kodu i zwykle żadnego specjalnego wsparcia IDE nie ma.
A rust z wnioskowaniem typów jest bliżej nawet tego haskella.
@jarekr000000 może gdyby były jakieś naturalne koercje pomiędzy tymi & to by się dało, ale kiedy nie możesz porównać &int z intem, a gdzieś nagle dostajesz & albo w ogóle && to moim zdaniem jednak ciężko.
Swoją drogą, biorąc pod uwagę brak raw-pointerów jako takich (w sensie jakiegoś int* ptr = 0x12345; w C), zastanawiam się, czemu składnia idzie w kierunku pointerów z C (w kontekście & i *) a nie czegoś na wzór referencji.
@Shalom pisanie przez parę lat w C++ skłoniło mnie do konkluzji, że implicit referencje to zło wcielone. Semantyka wskaźników używana w C czy Javie jest prosta i skuteczna. To, że w zależności od kontekstu referencja zachowuje się jak wskazywany typ albo nie powoduje dużo problemów np. nieustanne niepotrzebne kopie, konieczne cuda na kiju (jak std::reference_wrapper) popieprzone wyłomy w systemie typów. Zauważ, że w wielu przypadkach Rust idzie na rękę i sprawia, że referencje są przezroczyste w przypadkach, gdy jest to całkowicie nieszkodliwe np. wołanie metod.
swap(x, y) a w C/Javie nie.
Shalomp_agonShalom