A comparação de iteradores begin()e de dois s que apontam para a mesma memória está bem definida?end()std::span

#include <span>
#include <cassert>

int main() {
    int arr[5]{1,2,3,4,5};
    std::span s1{arr};
    std::span s2{arr};
    assert(s1.begin() == s2.begin());
    assert(s1.end() == s2.end());
    assert(s1.begin() + s1.size() == s2.end());
}

Todas as afirmações passam em todas as implementações std::spanaté agora, mas há algo que eu possa estar esquecendo que torna isso um bug, por exemplo, UB?

Para contextualizar, isso pode ocorrer se você tiver uma classe que tenta esconder seus componentes internos com um span.

class some_class
{
public:
  std::span<int> vec_view() { return vec; }
private:
  std::vector<int> vec;
};

int main() {
    some_class c;
    std::for_each(c.vec_view().begin(), c.vec_view().end(), [](auto&){});
}

Isso está relacionado a C++ permite comparação entre std::span::iterators quando um span é um subspan do outro?, mas esta questão não é sobre um std::subspan, e além disso a std::spanversão também passa asserções MSVC, diferente da versão com o std::subspan.

Tenho um lambda operando std::arrayque é inicializado e às vezes reinicializado dentro do lambda:

std::array<int, 10> nums; // indeterminate values
auto reinitNums{true};

const auto lambda{
    [&] (auto&&... args) {
        // always initialized before first use
        if (reinitNums) {
            // ...
            reinitNums = false;
        }

        // use nums

        if (condition) {
            regenerateNums = true;
        }
    }
};

// call the lambda a number of times

O array e reinitNumsnão são usados ​​fora do lambda, então movê-los para a captura init pode ser desejável:

const auto lambda{
    [
        nums = std::array<int, 10>{}, // filled with zeros
        reinitNums = true
    ] (auto&&... args) mutable {
        if (reinitNums) {
            // rewrite the zeros
            reinitNums = false;
        }

        // as before
    }    
};

O problema é que isso aciona a inicialização de valor:

nums = std::array<int, 10>{}

O mesmo acontece com a versão entre parênteses:

nums = std::array<int, 10>()

Uma versão sem nenhuma delas nums = std::array<int, 10>não compila.

É possível ter uma captura init inicializada por padrão?

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?

Considerar:

typedef union 
{
    int intval;
    const int const_intval;
}myUnion_t;

int main(void)
{
    myUnion_t x = {0};

    x.intval = 5;

    printf("intval = %d\n", x.intval);
    printf("const_intval = %d\n", x.const_intval);
}

1. O próprio UB é myUnion_tdefinido como é aqui?
2. Existe alguma atribuição da intvalUB?

Nenhum dos compiladores testados emite aviso (compilados também com compiladores C++)

EDITAR

A duplicata está relacionada apenas à pergunta 2, não à principal.

Quero remover todas as duplicatas em vários vetores, sem deixar nenhuma. Por exemplo, para estes vetores:

a <- c("dog", "fish", "cow")
b <- c("dog", "horse", "mouse")
c <- c("cat", "sheep", "mouse")

o resultado esperado seria:

a <- c("fish", "cow")
b <- c("horse")
c <- c("cat", "sheep")

Existe uma maneira de fazer isso sem concatenar os vetores e dividi-los 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.

Estou gerando códigos de cores hexadecimais. Em R3.6.2

paste(as.hexmode(c(213,94,0)))

gera

 "d5" "5e" "00"

Enquanto em R4.4.1 ele gera

 "d5" "5e" "0"

resultando em um hexcode inválido ( "#d55e0") e código quebrado

paste()agora parece não reconhecer o atributo 'hexmode' - em vez disso, trata o resultado de as.hexmode() como um inteiro simples. Essa mudança é esperada?

Hoje encontrei aqui uma sintaxe um tanto estranha - where ():
https://github.com/binator/self/tree/80ba2ade?tab=readme-ov-file#example

fn hex_primary<Stream, Context>(stream: Stream) -> Parsed<u8, Stream, Context>
where
  (): IntRadixParse<Stream, Context, u8>,
{
  uint_radix(2, Radix::HEX).parse(stream)
}

Para mim parece "limitado ao tipo unitário (também conhecido como tupla vazia )", mas não consigo entender. Um tipo unitário não implementa todas as características por padrão, certo? Infelizmente, a documentação oficial é muito vaga e não é completa o suficiente (ao mesmo tempo em que é excessivamente prolixa), e não consegui encontrar nada relacionado nela.

A cláusula RFC for original wheretambém menciona essa sintaxe, mas sem explicação adequada:
https://rust-lang.github.io/rfcs/0135-where.html#alternatives

fn increment<T>(c: T) -> T
    where () : Add<int,T,T>
{
    1 + c
}

Mas além disso, eu sei que tais limites podem ser especificados não apenas em genéricos de traits.
Então o que é, quando é usado, por que é necessário e quais problemas ele resolve?

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.

Considere este código:

library(dplyr)
a = data.frame(a = 1:3)
abc = \(x) data.frame(x/2, x/3)
a %>% 
  mutate(abc(a))

que retorna

  a x.2       x.3
1 1 0.5 0.3333333
2 2 1.0 0.6666667
3 3 1.5 1.0000000

mas não tenho controle sobre os nomes, pois quero atribuir outra coisa a eles.

abcUma maneira de resolver isso é nomear o tipo de retorno, mas isso não é o ideal, pois posso querer executar abcem dois conjuntos de variáveis

a %>% 
  mutate(abc(a), abc(b))

A outra maneira é, claro, renamedepois de cada execução, abcmas isso pode ser instável.

Existe alguma maneira de dar nomes à saída de abc? por exemplo

a %>% 
  mutate(c("a1","a2") := abc(a), c("b1","b2") := abc(b))

Mas a :=sintaxe acima não funcionou.