All perguntas(coding)

Da página 99 de K&R:

"preferimos o último porque diz mais explicitamente que a variável é um ponteiro."

Preciso de algum esclarecimento sobre por que "dizer mais explicitamente que a variável é um ponteiro" teria alguma importância? Eu esperaria que o motivo fosse para o programa ser mais rápido, em vez de mais explícito, como declarado na página 97:

"A versão do ponteiro será, em geral, mais rápida, mas, pelo menos para os não iniciados, um pouco mais difícil de entender"

Mas nesse caso, por que a versão do ponteiro seria mais rápida? Se arr[i]for equivalente a isso, *(a+i)por que o programa seria mais rápido? É porque C não precisa converter o array para a versão do ponteiro?

"Desinstalamos 'equinusocio.vsc-material-theme', que foi relatado como problemático."

Essa notificação ainda aparece toda vez que atualizo o VScode.

Já tentei remover manualmente a extensão da pasta de extensões, mas toda vez que abro o VScode aparece um alerta pop-up informando que o VScode tentou instalá-la novamente.

Funções de substituição, como names<-, parecem não usar avaliação preguiçosa quando chamadas como names(x) <- c("a", "b").

Para demonstrar, vamos definir uma função para obter a parte fracionária de um número e uma função de substituição correspondente - mas dentro da função de substituição, inclua uma linha para imprimir o valueargumento neutralizado.

fractional <- function(x) { 
  x %% 1 
}

`fractional<-` <- function(x, value) {
  print(rlang::enexpr(value))
  invisible(x %/% 1 + value)
}

Agora, se chamarmos fractional<-diretamente, ele imprime a expressão que demos para value:

x <- 10.1
`fractional<-`(x, 0.2 + 0.2)
#> 0.2 + 0.2

Mas se o chamarmos no formulário de atribuição, ele imprime o resultado da avaliação da expressão:

x <- 10.1
fractional(x) <- 0.2 + 0.2
#> [1] 0.4

A definição da linguagem explica funções de substituição como:

names(x) <- c("a","b")

é equivalente a

`*tmp*` <- x
x <- "names<-"(`*tmp*`, value=c("a","b"))
rm(`*tmp*`)

Mas isso não reproduz esse comportamento:

x <- 10.1

`*tmp*` <- x
x <- "fractional<-"(`*tmp*`, value=0.2 + 0.2)
rm(`*tmp*`)

#> 0.2 + 0.2

O que está acontecendo internamente <-que faz com que valueseja passado para fractional<- depois de ser avaliado, e há alguma maneira de contornar esse comportamento?

Edição: @SamR destacou que usar substitutecaptura a expressão da promessa:

x <- 10.1
`fractional<-` <- function(x, value) {
  print(substitute(value))
  invisible(x %/% 1 + value)
}
fractional(x) <- 0.2 + 0.2

#> 0.2 + 0.2

Então, claramente eu estava enganado ao assumir que valueestava sendo avaliado antes de ser passado para fractional<-. No entanto, eu ainda gostaria muito de saber por que base::substitute funciona como esperado aqui enquanto rlang::enexpr e amigos não . Afinal, enexprusa substituteinternamente:

enexpr <- function(arg) {
  .Call(ffi_enexpr, substitute(arg), parent.frame())
}

A depuração no R Studio mostra que, tanto quando chamado na forma de atribuição como fractional(x) <- 0.2 + 0.2quanto na forma de prefixo "fractional<-"(x, 0.2 + 0.2), fractional<-é passada uma promessa não avaliada para value:

Isso permanece não avaliado quando chamado na forma de prefixo:

Mas é avaliado após a chamada para enexprquando chamado no formulário de atribuição:

Estou pensando se isso tem a ver com o fato de que no formulário de atribuição, a função é chamada por uma função primitiva, <-? Mas não está claro por que isso faria diferença.

No Java 21 e 23, java.net.InetAddressé declarado

public sealed class InetAddress implements Serializable permits Inet4Address, Inet6Address {

Entretanto, o seguinte código:

switch (addr) {
     case Inet4Address a -> ...;
     case Inet6Address a -> ...;
};

não compila com:

the switch expression does not cover all possible input values

Estou esquecendo de alguma coisa ou isso é um bug do Java?

O std::align_val_ttipo é definido como:

namespace std
{
    enum class align_val_t : size_t
    {
    };
}

Qual é o propósito de uma enumeração tão vazia?

Qual é a diferença com um typedef?

Considere este programa vazio:

int main()
{ return 0; }

Se eu compilar com C++ com g++ main.cpp && strace ./a.out, e analisar a saída com strace, observei que as últimas linhas da saída são (você pode acrescentar -O3que o efeito é o mesmo):

mprotect(0x7f71af154000, 45056, PROT_READ) = 0
mprotect(0x7f71af38b000, 4096, PROT_READ) = 0
brk(NULL)                               = 0xed2000
brk(0xf05000)                           = 0xf05000
exit_group(0)                           = ?
+++ exited with 0 +++

No entanto, se eu fizer isso:gcc main.cpp && strace ./a.out

mprotect(0x7f4114318000, 16384, PROT_READ) = 0
mprotect(0x7f4114547000, 4096, PROT_READ) = 0
exit_group(0)                           = ?
+++ exited with 0 +++

Como você vê, em C++ há um extra brkque estende o heap em exatamente 204 KB (0xf05000 - 0xed2000 = 204 KB após traduzir ambos para decimal). Isso pode ser facilmente verificado substituindo esse programa por ( link coliru ):

#include <iostream>
#include <unistd.h>

int main()
{
    char buf[1024];
    sprintf(buf, "pmap -XX %u", getpid());
    std::system(buf);
    
    return 0;
}

e você pode facilmente observar que a compilação com g++o [heap]tem um tamanho de 204 KB, e com gcca [heap]linha até desapareceu da pmapsaída.

NOTA: A propósito, e para minha surpresa, o gcc não teve nenhum problema com include <iostream>e com a presença de stdin std::system.

Para que servem esses 204 KB? Não estou preocupado nem nada sobre esses pequenos 204 KB, mas eles chamaram minha atenção e estou curioso agora.

O código a seguir produz um assembly que executa condicionalmente o SIMD no GCC 12.3 quando compilado com -O3. Para completar, o código sempre executa SIMD no GCC 13.2 e nunca executa SIMD no clang 17.0.1.

#include <array>

__attribute__((noinline)) void fn(std::array<int, 4>& lhs, const std::array<int, 4>& rhs)
{
    for (std::size_t idx = 0; idx != 4; ++idx) {
        lhs[idx] = lhs[idx] + rhs[idx];
    }
}

Aqui está o link em godbolt.

Aqui está a montagem real do GCC 12.3 (com -O3):

fn(std::array<int, 4ul>&, std::array<int, 4ul> const&):
        lea     rdx, [rsi+4]
        mov     rax, rdi
        sub     rax, rdx
        cmp     rax, 8
        jbe     .L2
        movdqu  xmm0, XMMWORD PTR [rsi]
        movdqu  xmm1, XMMWORD PTR [rdi]
        paddd   xmm0, xmm1
        movups  XMMWORD PTR [rdi], xmm0
        ret
.L2:
        mov     eax, DWORD PTR [rsi]
        add     DWORD PTR [rdi], eax
        mov     eax, DWORD PTR [rsi+4]
        add     DWORD PTR [rdi+4], eax
        mov     eax, DWORD PTR [rsi+8]
        add     DWORD PTR [rdi+8], eax
        mov     eax, DWORD PTR [rsi+12]
        add     DWORD PTR [rdi+12], eax
        ret

Estou muito interessado em saber a) o propósito das primeiras 5 instruções de montagem eb) se há algo que possa ser feito para fazer com que o GCC 12.3 emita o código do GCC 13.2 (idealmente, sem escrever manualmente o SSE).

Do documento diz:

pub fn new(x: T) -> Box Aloca memória no heap e depois coloca x nele.

Mas “lugar” é uma palavra complicada. Se escrevermos

let arr_boxed = Box::new([0;1000]);

Será [0;1000]inicializado no heap no local?

Se escrevermos

let arr = [0;1000];
let arr_boxed = Box::new(arr);

O compilador será inteligente o suficiente para inicializar o [0;1000]heap em primeiro lugar?

Esta é a desmontagem de uma compreensão de lista em python 3.10:

Python 3.10.12 (main, Jun 11 2023, 05:26:28) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import dis
>>> 
>>> dis.dis("[True for _ in ()]")
  1           0 LOAD_CONST               0 (<code object <listcomp> at 0x7fea68e0dc60, file "<dis>", line 1>)
              2 LOAD_CONST               1 ('<listcomp>')
              4 MAKE_FUNCTION            0
              6 LOAD_CONST               2 (())
              8 GET_ITER
             10 CALL_FUNCTION            1
             12 RETURN_VALUE

Disassembly of <code object <listcomp> at 0x7fea68e0dc60, file "<dis>", line 1>:
  1           0 BUILD_LIST               0
              2 LOAD_FAST                0 (.0)
        >>    4 FOR_ITER                 4 (to 14)
              6 STORE_FAST               1 (_)
              8 LOAD_CONST               0 (True)
             10 LIST_APPEND              2
             12 JUMP_ABSOLUTE            2 (to 4)
        >>   14 RETURN_VALUE

Pelo que entendi ele cria um objeto de código chamado listcompque faz a iteração real e retorna a lista de resultados, e o chama imediatamente. Não consigo entender a necessidade de criar uma função separada para executar este trabalho. Isso é um tipo de truque de otimização?

Fundo:

Estou tentando portar uma biblioteca para compilar no MSVC. Essa biblioteca armazena dados em uma tupla de vetores ( std::tuple<std::vector<Ts>...>) e usa um iterador personalizado para iterar todos os vetores simultaneamente (semelhante ao que faz um zip_iterator).

O iterador define tipos que se parecem com isso (assumindo Ts...-> <int, int>):

`value_type` is `std::tuple<int, int>`  
`reference`  is `std::tuple<int&, int&>`

O problema é que no MSVC mais recente (v. 19.35), esse iterador não satisfaz o conceito de std::input_iterator, embora o satisfaça no gcc/clang.

Em uma investigação mais aprofundada, descobri que a falha se deve ao comportamento inconsistente do std::common_referenceconceito em tuplas.

Emitir:

O seguinte static_assertfalha no MSVC, enquanto não falha no gcc/clang

using T = std::tuple<int, int>&;
using U = std::tuple<int&, int&>;
static_assert(std::common_reference_with<T, U>, "failed common_reference_with");

Aqui está em Godbolt (com um exemplo de iterador também)

Pergunta:

Um tipo como std::tuple<int, int>&deveria ter um " common_reference_with" std::tuple<int&, int&>? MSVC diz que não, gcc diz que sim.
Qual dos dois comportamentos deve ser esperado de acordo com o padrão em C++20 e posteriores?

Existe alguma maneira fácil de fazer com que esse iterador seja bem-sucedido nas verificações de conceito do iterador no MSVC (ou seja, forçar os dois tipos a terem uma referência comum)?

Também encontrei ótimas respostas de Eric Niebler, em std::common_reference (SO) e em proxy iterators (em seu blog) .

No entanto, não está claro para mim o que deve acontecer no C++ 20 e posterior.