Some Name's questions

Considere o seguinte exemplo simples:

use std::cell::RefCell;

// Compiles fine
fn good(t: RefCell<String>) -> bool {
    t.borrow().len() == 12
}

// error[E0597]: `t` does not live long enough
fn bad(t: RefCell<String>) -> bool {
    let t = t;
    t.borrow().len() == 12
}

Parque infantil

A badfunção falha ao compilar com o seguinte erro:

error[E0597]: `t` does not live long enough
  --> src/lib.rs:9:5
   |
8  |     let t = t;
   |         - binding `t` declared here
9  |     t.borrow().len() == 12
   |     ^---------
   |     |
   |     borrowed value does not live long enough
   |     a temporary with access to the borrow is created here ...
10 | }
   | -
   | |
   | `t` dropped here while still borrowed
   | ... and the borrow might be used here, when that temporary is dropped and runs the destructor for type `Ref<'_, String>`
   |
   = note: the temporary is part of an expression at the end of a block;
           consider forcing this temporary to be dropped sooner, before the block's local variables are dropped
help: for example, you could save the expression's value in a new local variable `x` and then make `x` be the expression at the end of the block
   |
9  |     let x = t.borrow().len() == 12; x
   |     +++++++                       +++

Isso parece extremamente estranho para mim. Apenas reatribuir o parâmetro de função a variáveis ​​locais falha na compilação. Você poderia explicar por quê?

Exemplo:

use std::ops::Index;

fn test(v: &Vec<Vec<i32>>) {  
    let t = v.index(0); //ok
    let t = v[0]; //error, Vec<i32> does not implement Copy trait
}

Parque infantil

Por que isso acontece? Conforme especificado na documentação :

fn index(&self, index: I) -> &<Vec<T, A> as Index<I>>::Output

Executa a container[index]operação de indexação ( )

Então deveria ser o mesmo.

Aqui está o exemplo:

fn bar<T>(v: &mut Vec<T>) {
    bar(v); //reborrows
    bar(v); //reborrows
}

que compila bem. Mas considere uma versão ligeiramente modificada:

fn foo<T>(v: &mut Vec<T>) {
    let mut f = ||{
        foo(v);
    };
    let mut g = ||{
        foo(v);
    };
    f();
    g();
}

O que temos aqui é um erro de compilação:

error[E0524]: two closures require unique access to `*v` at the same time
 --> src/lib.rs:5:17
  |
2 |     let mut f = ||{
  |                 -- first closure is constructed here
3 |         foo(v);
  |             - first borrow occurs due to use of `*v` in closure
4 |     };
5 |     let mut g = ||{
  |                 ^^ second closure is constructed here
6 |         foo(v);
  |             - second borrow occurs due to use of `*v` in closure
7 |     };
8 |     f();
  |     - first borrow later used here

Parque infantil

Acho que a mensagem de erro está relacionada a várias referências mutáveis ​​ao mesmo tempo. Mas no primeiro exemplo também há múltiplas referências ao mesmo tempo. Isso é muito confuso.

Considere o seguinte código:

fn main() {
    let foo = 1;
    let bar: i32 = -&foo; //ok, -1
    let baz: i32 = &foo;  //error, expected `i32`, found `&{integer}`
    let bad: i32 = !&foo; //ok, -2
}

Parque infantil

Lendo a referência de ferrugem, descobri que

Os possíveis locais de coerção são:

• let instruções onde um tipo explícito é fornecido.

[...]

• Argumentos para chamadas de função

Portanto, let baz: i32 = &foo;também deve funcionar, pois é uma instrução let com um tipo explícito fornecido.

Por que ele se recusa a ser compilado?

Considere a definição de compare_and_exchange_strong_explicit:

_Bool atomic_compare_exchange_strong_explicit( volatile A* obj,
                                               C* expected, C desired,
                                               memory_order succ,
                                               memory_order fail );

Estou confuso com o caso de uso do memory_order fail. Considerando o x86, está perfeitamente claro que lock cmpxchgpode falhar, mas também está claramente definido que (enfatize o meu)

Leituras ou gravações não podem ser reordenadas com instruções de E/S, instruções bloqueadas ou instruções de serialização

o que torna o memory_order failtipo irrelevante, pois lockgarante consistência sequencial em qualquer caso.

Exemplo :

#include <stdatomic.h>

void fail_seqcst(volatile int *p, int *expected, int *desirable){
    atomic_compare_exchange_strong_explicit(p, expected, desirable, memory_order_release, memory_order_seq_cst);
}

void fail_relaxed(volatile int *p, int *expected, int *desirable){
    atomic_compare_exchange_strong_explicit(p, expected, desirable, memory_order_release, memory_order_relaxed);
}

Compila para :

fail_relaxed:
        mov       ecx, edx                                      
        mov       eax, DWORD PTR [rsi]                          
        lock      
        cmpxchg   DWORD PTR [rdi], ecx                          
        mov       DWORD PTR [rsi], eax                          
        sete      al                                            
        movzx     eax, al                                       
        ret 

fail_seqcst:
        mov       ecx, edx                                      
        mov       eax, DWORD PTR [rsi]                          
        lock      
        cmpxchg   DWORD PTR [rdi], ecx                          
        mov       DWORD PTR [rsi], eax                          
        sete      al                                            
        movzx     eax, al                                       
        ret                                                     

Raio Deus

Existe alguma otimização que o compilador possa fazer que diferencie o código memory_order_relaxede, memory_order_seq_cstnesse caso, em x86? Ou talvez exista uma arquitetura que possa tornar essa diferença significativa?

Considere o seguinte código:

class SomeClass {

    companion object {
        val str = "My String"
        object AnotherObject {
             fun foo(str: String) {
                  return str + //companion object's str
             }
        }
    }
}

Como fazer referência SomeClass::companion object::strde AnotherObject::foo?

Considere o seguinte exemplo compilado com -O3 -march=native:

struct str{
    volatile uint64_t a1;
    volatile uint64_t a2;
    volatile uint64_t a3;
    volatile uint64_t a4;
};

int main(void){
    struct str str1;
    struct str str2;
    str1.a1 = str2.a2;
    str1.a2 = str2.a2;
    str1.a3 = str2.a3;
    str1.a4 = str2.a4;
}

Ele produz o seguinte código assembly:

main:
        push    rbp
        vpxor   xmm0, xmm0, xmm0
        vmovdqu8        YMMWORD PTR [rsp-32], ymm0
        mov     rbp, rsp
        mov     rax, QWORD PTR [rsp-24]
        mov     QWORD PTR [rsp-64], rax
        mov     rax, QWORD PTR [rsp-24]
        mov     QWORD PTR [rsp-56], rax
        mov     rax, QWORD PTR [rsp-16]
        mov     QWORD PTR [rsp-48], rax
        mov     rax, QWORD PTR [rsp-8]
        mov     QWORD PTR [rsp-40], rax
        xor     eax, eax
        vzeroupper
        pop     rbp
        ret

exemplo ao vivo de godbolt

Na minha máquina, KbL i7-8550Uele produz praticamente o mesmo código de máquina:

(gdb) disas main
Dump of assembler code for function main:
   pxor   xmm0,xmm0
   movaps XMMWORD PTR [rsp-0x28],xmm0
   mov    rax,QWORD PTR [rsp-0x20]
   movaps XMMWORD PTR [rsp-0x18],xmm0
   mov    QWORD PTR [rsp-0x48],rax
   mov    rax,QWORD PTR [rsp-0x20]
   mov    QWORD PTR [rsp-0x40],rax
   mov    rax,QWORD PTR [rsp-0x18]
   mov    QWORD PTR [rsp-0x38],rax
   mov    rax,QWORD PTR [rsp-0x10]
   mov    QWORD PTR [rsp-0x30],rax
   xor    eax,eax
   ret    

Na minha máquina há suporte para avx2, mas não SIMDé usado para copiar.

Como sugerir gcco uso 256 bitbaseado SIMD(já que a estrutura tem 256 bytes de tamanho)?

Tentei escrever o seguinte código:

val s: Function<String, String> = { s -> s + s }

Ele compila com o seguinte erro:

Type mismatch: inferred type is (???) -> [Error type: Return type for function cannot be resolved] but Function<String, String> was expected

Cannot infer a type for this parameter. Please specify it explicitly.

Qual é a maneira correta de atribuir Kotlinlambda à Javafunção?