@@ -157,6 +231,12 @@ a = String::from("hello");
"Variável a tem o valor "hello""
+
+
+ Em todas as linguagens que eu usei, sempre que via
+ uma atribuição, eu pensava "a variável X tem o
+ valor Y" -- mesmo em C.
+
@@ -170,7 +250,24 @@ a = String::from("hello");
-
+ Nunca uma linguagem me fez "despensar" no nome da
+ variável pra pensar que ela representa, na verdade,
+ uma posição de memória.
+
+
+
+
+
+ É mais ou menos isso que Rust "pensa" internamente
+ quando vê uma variável: uma posição de memória, de
+ um tamanho já definido, de um tipo definido.
+
+ E essa posição de memória *pertence* apenas à
+ variável indicada.
+
@@ -206,12 +303,24 @@ error[E0382]: borrow of moved value: `a`
|
= note: move occurs because `a` has type `std::string::String`, which does not implement the `Copy` trait
+
+
+ O borrow checked não deixa a variável "a" ser
+ utilizada: quando a atribuímos "_b" o valor de "a",
+ o que estamos fazendo é indicando que aquela
+ posição de memória agora é controlada por "_b" e
+ não mais por "a".
+
E se eu precisar acessar a variável em mais de um lugar?
References
+
+
+ Assim como C++, Rust tem o conceito de "referências".
+
@@ -225,7 +334,12 @@ fn main() {
-
+ Uma referência nada mais é que um ponteiro para um
+ "controlador" de uma região de memória.
+
@@ -238,6 +352,16 @@ fn main() {
A região é desalocada quando o dono sair de escopo.
+
+
+ Uma coisa engraçada sobre "quando sair de escopo" é
+ que existe uma função semelhante ao "free()" do C,
+ chamada "drop". Essa função não tem nada no corpo,
+ e recebe um parâmetro (sem ser por referência), se
+ tornando a dona da memória; assim, como ela termina
+ exatamente naquele ponto, a região de memória é
+ liberada.
+
@@ -250,6 +374,14 @@ fn main() {
... desde que elas não durem mais do que o dono.
+
+
+ Não é possível ter uma função que cria uma variável
+ e retorna apenas uma referência para essa variável:
+ no momento que a função for encerrada, ela irá
+ levar todas as variáveis com ela e as referências
+ se tornaram inválidas.
+
@@ -267,22 +399,54 @@ fn main() {
+ E o que isso ajuda, no final das contas?
+
presente := Presente { ... }
canal <- presente
+ Num exemplo em Go, criamos uma estrutura e passamos
+ essa estrutura para outra thread através de um
+ canal.
+
presente := Presente { ... }
canal <- presente
presente.abrir()
+ ... e depois de passar o presente pra outra pessoa,
+ nós abrimos o presente.
+
+ Mas se estamos entregando um presente pra alguém,
+ como é que estamos abrindo o presente?
+
+ O borrow checker não permite esse tipo de coisa:
+ Ele irá barrar a função atual de continuar
+ utilizando a variável porque, afinal de contas,
+ agora a região de memória pertence à outra função
+ (uma função que está rodando em outra thread).
+
Swift 5 Exclusivity Enforcement
+
+
+ A ideia do borrow checker é tão interessante que
+ até o Swift 5 agora tem o seu próprio borrow
+ checker (com outro nome, mas o princípio da coisa é
+ basicamente o mesmo, apesar de ser um pouco mais
+ leve no Swift).
+
@@ -297,6 +461,32 @@ presente.abrir()
localtime
SimpleDateFormatter
+
+
+ A muito tempo atrás, eu estava ajudando uma colega
+ a resolver um problema com processamento de eventos
+ num projeto em C. Aparentemente, quando um evento
+ era processado, acontecia do tempo de processamento
+ ficar errado (algo como ficar negativo ou levar
+ menos de 10ms pra fazer uma query num banco
+ oracle). Quando perguntei como ela estava
+ calculando o tempo, ela me falou que estava usando
+ o "localtime". Foi quando me lembrei que
+ "localtime" não é thread-safe e, por isso, quando
+ uma thread passava pela chamada da função, o valor
+ era "resetado".
+
+ Outra situação aconteceu recentemente: Num projeto
+ Java, começou a acontecer de, em alguns casos, a
+ função que convertia strings para Date começou a
+ dar resultados completamente errados.
+ Estranhamente, eu lembrei da questão do localtime e
+ perguntei se o projeto usava threads: sim; fui
+ direto no DuckDuckGo e procurei por
+ "simpledateformatter thread safe" e o primeiro
+ resultado foi uma pergunta do StackOverflow: "Why
+ isn't SimpleDateFormatter thread-safe?"
+
+
+
+ 
+
+ 
+ 
+
+