coding

Os conjuntos não são ordenados, ou melhor, sua ordem é um detalhe de implementação. Estou interessado nesse detalhe. E vi um caso que me surpreendeu:

print({2, 3, 10})
x = 2
print({x, 3, 10})

Saída ( tente fazer isso online! ):

{3, 10, 2}
{10, 2, 3}

Apesar de elementos idênticos escritos em ordem idêntica, eles são ordenados de forma diferente. Como isso acontece, e isso é feito intencionalmente por algum motivo, por exemplo, para otimizar a velocidade de pesquisa?

Meu sys.versione sys.implementation:

3.13.0 (main, Nov  9 2024, 10:04:25) [GCC 14.2.1 20240910]
namespace(name='cpython', cache_tag='cpython-313', version=sys.version_info(major=3, minor=13, micro=0, releaselevel='final', serial=0), hexversion=51183856, _multiarch='x86_64-linux-gnu')

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?

Não estou compilando nada para nativo , em outras palavras, não estou usando native-imagedo GraalVM. Estou apenas executando a mesma classe Java (mesmo bytecode Java) com o GraalVM e, em seguida, executando a mesma classe Java (mesmo bytecode Java) com Oracle JVMs regulares.

Não importa qual versão do Java eu ​​uso ou plataforma (eu testei em Linux e Mac). GraalVM é sempre muito mais rápido (30x) do que qualquer outra JVM regular.

Parece que as JVMs regulares não estão otimizando o método corretamente com seu JIT. Observe que o método é muito simples e pequeno.

Alguém tem alguma ideia do porquê esse é o caso e como eu poderia consertar isso na minha JVM regular? A única solução alternativa no momento é migrar para o GraalVM. É muito fácil compilar e executar o código abaixo para reproduzir o problema. Basta compilar e executar primeiro com uma JVM Oracle e depois com qualquer JVM Graal para ver a diferença.

Obrigado!

public class OracleJvm23MathBug {

    // simple and small amount of math
    // =====> should be optimized/compiled/inlined for sure!
    private static final long doSomething(int load, int i) {
        long x = 0;
        for (int j = 0; j < load; j++) {
            long pow = (i % 8) * (i % 16);
            if (i % 2 == 0) {
                x += pow;
            } else {
                x -= pow;
            }
        }
        return x;
    }

    /*
     * Execute this with OpenJDK/Zulu/Oracle JVM 23 => average 215 nanoseconds
     * Now execute this with Graal23 JVM 23 => average 7 nanoseconds
     * 
     * This bug can be observed in any platform (I tested on Linux and Mac)
     * 
     * $ java -version 
     * java version "23.0.1" 2024-10-15 
     * Java(TM) SE Runtime Environment (build 23.0.1+11-39)
     * Java HotSpot(TM) 64-Bit Server VM (build 23.0.1+11-39, mixed mode, sharing)
     * 
     * $ java -cp . OracleJvm23MathBug
     * Value computed: -550000000000
     * Measurements: 10000000| Avg Time: 215 nanos | Min Time: 83 nanos | Max Time: 199750 nanos
     * 
     * $ java -version
     * java version "23.0.1" 2024-10-15
     * Java(TM) SE Runtime Environment Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01)
     * Java HotSpot(TM) 64-Bit Server VM Oracle GraalVM 23.0.1+11.1 (build 23.0.1+11-jvmci-b01, mixed mode, sharing)
     * 
     * $ java -cp . OracleJvm23MathBug
     * Value computed: -550000000000
     * Measurements: 10000000| Avg Time: 7 nanos | Min Time: 0 nanos | Max Time: 178625 nanos
     */
    public static final void main(String[] args) {
        final int iterations = 10_000_000;
        final int load = 10_000;
        NanoBench bench = new NanoBench();
        long computed = 0;
        for (int i = 0; i < iterations; i++) {
            bench.mark();
            computed += doSomething(load, i);
            bench.measure();
        }
        System.out.println("Value computed: " + computed);
        bench.printResults();
    }

    private static class NanoBench {

        private int measurements;
        private long totalTime, minTime, maxTime, time;
        private final StringBuilder sb = new StringBuilder(128);

        NanoBench() {
            reset();
        }

        public final void reset() {
            totalTime = time = measurements = 0;
            maxTime = Long.MIN_VALUE;
            minTime = Long.MAX_VALUE;
        }

        public final void mark() {
            time = System.nanoTime();
        }

        public final void measure() {
            long lastNanoTime = System.nanoTime() - time;
            totalTime += lastNanoTime;
            minTime = lastNanoTime < minTime ? lastNanoTime : minTime;
            maxTime = lastNanoTime > maxTime ? lastNanoTime : maxTime;
            measurements++;
        }

        public final void printResults() {
            sb.setLength(0);
            sb.append("Measurements: ").append(measurements);
            sb.append("| Avg Time: ").append((long) (totalTime / (double) measurements)).append(" nanos");
            sb.append(" | Min Time: ").append(minTime).append(" nanos");
            sb.append(" | Max Time: ").append(maxTime).append(" nanos\n\n");
            for (int i = 0; i < sb.length(); i++) System.out.print(sb.charAt(i));
        }
    }
}

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?

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?

Há algum tempo, me deparei com a ideia de como uma construção C, como (expr0, expr1, expr2), é avaliada (veja "O que o operador vírgula , faz?" para mais contexto).

Comecei a experimentar isso, especialmente dentro de macros do tipo função, e recentemente encontrei um código que é rejeitado por alguns compiladores, enquanto aceito por outros. Parece similar ao seguinte trecho:

#include <stdio.h>

int main(void)
{
    int arr[] = {0};
    (1, arr[0]) = 30;  // <--- potentially (in)valid code
    printf("%d\n", arr[0]);
    return 0;
}

Como você pode ver, para que isso funcione, (1, arr[0])deve ser avaliado para lvalue arr[0], caso contrário a atribuição NÃO seria possível. No entanto, não tenho certeza se esse comportamento é válido ou não. Ele "faz sentido" e eu encontrei um uso para ele, mas também vejo por que os desenvolvedores do compilador o rejeitariam.

O código acima é rejeitado pelo gcc, clang e msvc (observe que o msvc é principalmente um compilador C++, enquanto o gcc e o clang são front-ends C):

$ gcc main.c
main.c: In function ‘main’:
main.c:6:21: error: lvalue required as left operand of assignment
    6 |         (1, arr[0]) = 30;
      |                     ^

$ clang main.c -Wno-unused-value
main.c:6:14: error: expression is not assignable
    6 |         (1, arr[0]) = 30;
      |         ~~~~~~~~~~~ ^
1 error generated.

$ cl main.c /nologo
main.c
main.c(6): error C2106: '=': left operand must be l-value

Para efeito de comparação, g++, clang++ e tcc funcionam bem com o código mencionado (observe que tcc é um compilador C, enquanto g++ e clang++ são front-ends C++):

$ tcc main.c && ./a.out
30

$ g++ main.c && ./a.out
30

$ clang++ main.c -Wno-unused-value -Wno-deprecated && ./out
30

Também tentei com algumas opções de comando diferentes, como definir explicitamente o msvc para ser executado nos modos /std:c++lateste /std:c99, ou definir algo diferente -stdpara gcc/clang/g++/clang++, mas isso não mudou nada.

No começo, pensei que fosse um bug dentro do tcc, já que é o único compilador C que não rejeita o código "defeituoso", mas então verifiquei os front-ends C++ e não tenho mais tanta certeza sobre isso. Especialmente porque o msvc o rejeita, diferentemente do g++/clang++.

• O código que acabei de apresentar é um C válido, ou C++, ou ambos/nenhum?
• Os padrões C/C++ descrevem o que deve acontecer aqui?
• Quais compiladores estão certos/errados aqui? (tcc e msvc parecem muito estranhos)

Para referência, estou no Linux x86_64, usando gcc/g++ 14.2.1, clang 18.1.8, msvc 19.40.33811 (executando através do wine) e tcc 0.9.28rc (mob@08a4c52d).

Há uma novidade std::inplace_vectorna biblioteca padrão C++ que parece ter uma capacidade fixa definida em tempo de compilação. Estou tentando entender um caso de uso para std::inplace_vectorinstead of std::arrayor std::vector. Parece que std::inplace_vectortem a vantagem de uma capacidade de tamanho fixo , como std::array, mas em vez disso não requer inicialização de objeto até a inserção. Mas, diferentemente de std::vector, std::inplace_vectortem uma capacidade de tempo de compilação fixa.

Alguém pode dar um exemplo de onde std::inplace_vectorisso pode ser útil?

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 seguinte script bash:

#!/bin/bash

TEST_VAR=""

if [[ -z $TEST_VAR ]] then
    echo "empty"
else
    echo "$TEST_VAR"
fi

apesar de faltar um ponto e vírgula antes de "then", não gera erro no bash 5.2 e é concluído com sucesso, retornando até 0.

Executar o script acima em um sistema executando o bash 5.1 ou 5.0 falha como esperado.

Por que isso? O bash mudou seu parser na versão 5.2? Depois de pesquisar, não consegui encontrar nenhuma referência a essa mudança. O bash mudou o comportamento aqui intencionalmente ou isso é um bug?

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.

Como parte do nosso curso de introdução à segurança de computadores, temos uma breve unidade sobre injeções de SQL. Uma das tarefas de casa é uma página de login básica e não higienizada. A solução esperada é algo nos moldes do clássico ' or 1=1; -- , mas sempre recebemos estudantes para encontrar soluções não convencionais.

Uma dessas soluções me foi apresentada recentemente: a inserção '--'da senha parece realizar uma injeção de SQL bem-sucedida. Isso faria com que a consulta fosse avaliada como algo como:
SELECT * FROM users WHERE name='admin' AND password=''--'';

Aqui, --'';não é analisado como um comentário, pois o MariaDB exige que os comentários sejam seguidos de espaços. Na verdade, se o traço duplo fosse analisado como um comentário, esta consulta não retornaria nada; de forma equivalente, teríamos password='', que seria avaliado como falso, assumindo uma senha não vazia.

O par extra de aspas no final parece ser necessário: deixá-lo como password=''--;ou inserir outros dados atrás dele ( password=''--1;) faz com que a condicional seja avaliada como falsa, conforme esperado.

Alguns testes rápidos não conseguem reproduzir esse comportamento em outros bancos de dados - até onde eu sei, esse é um comportamento específico do MariaDB. A documentação confirma que dois travessões sem espaço não são analisados ​​como um comentário, mas não detalha como são analisados. EDIT: De alguma forma, consegui ignorar o fato de que isso também acontece no MySQL. Na verdade, esse comportamento ocorre em qualquer fork do MySQL (não apenas no MariaDB).

O que --acontece quando não é seguido por um espaço e por que faz com que as comparações sejam avaliadas como verdadeiras?

Um exemplo de brinquedo:

CREATE TABLE users (
  userid INTEGER PRIMARY KEY,
  username TEXT NOT NULL,
  password TEXT NOT NULL
);

INSERT INTO users VALUES (0001, 'admin', 'S3cur3P4ssw0rd!');
INSERT INTO users VALUES (0002, 'generic_user', 'Password');

SELECT * FROM users WHERE username='admin' AND password=''; -- empty password, query returns no users
SELECT * FROM users WHERE username='admin' AND password=''-- ''; -- parsed as comment, equivalent to above query, returns no users
SELECT * FROM users WHERE username='admin' AND password=''--''; -- query returns admin user
SELECT * FROM users WHERE username='admin' AND password=''--; -- query returns zero users
SELECT * FROM users WHERE username='admin' AND password=''--1; -- query returns zero users

Normalmente, se você tentar passar vários valores para o mesmo argumento de palavra-chave, obterá um TypeError:

In [1]: dict(id=1, **{'id': 2})
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
Input In [1], in <cell line: 1>()
----> 1 dict(id=1, **{'id': 2})

TypeError: dict() got multiple values for keyword argument 'id'

Mas se você fizer isso enquanto lida com outra exceção , você receberá um KeyError:

In [2]: try:
   ...:     raise ValueError('foo') # no matter what kind of exception
   ...: except:
   ...:     dict(id=1, **{'id': 2}) # raises: KeyError: 'id'
   ...: 
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [2], in <cell line: 1>()
      1 try:
----> 2     raise ValueError('foo') # no matter what kind of exception
      3 except:

ValueError: foo

During handling of the above exception, another exception occurred:

KeyError                                  Traceback (most recent call last)
Input In [2], in <cell line: 1>()
      2     raise ValueError('foo') # no matter what kind of exception
      3 except:
----> 4     dict(id=1, **{'id': 2})

KeyError: 'id'

O que está acontecendo aqui? Como uma exceção completamente não relacionada poderia afetar o tipo de exceção dict(id=1, **{'id': 2})lançada?

Para contextualizar, descobri esse comportamento ao investigar o seguinte relatório de bug: https://github.com/tortoise/tortoise-orm/issues/1583

Isso foi reproduzido no CPython 3.11.8, 3.10.5 e 3.9.5.

Vote no rastreador de problemas https://issuetracker.google.com/issues/330368298

Acabei de notar algumas falhas em meu aplicativo observando o Firebase Crashlytics, que parece estar relacionado à biblioteca da Google AdMob que tenta usar, SharedPreferencesmas não consegue obter uma preferência devido à exceção de conversão:

Texto do código:

Fatal Exception: java.lang.ClassCastException
java.lang.Integer cannot be cast to java.lang.String
android.app.SharedPreferencesImpl.getString (SharedPreferencesImpl.java:302)
com.google.android.gms.ads.internal.scionintegration.a.onSharedPreferenceChanged (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:73)
com.google.android.gms.ads.internal.scionintegration.m.a (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:106)
com.google.android.gms.ads.nonagon.a.s (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:439)
com.google.android.gms.ads.nonagon.a.b (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:5)
com.google.android.gms.ads.ChimeraMobileAdsSettingManagerCreatorImpl.getMobileAdsSettingManager (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:52)
com.google.android.gms.ads.internal.client.bx.bR (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:40)
m.ajn.onTransact (:com.google.android.gms.policy_ads_fdr_dynamite@[email protected]:21)
android.os.Binder.transact (Binder.java:1173)
obj.gL (:com.google.android.gms@[email protected] (190400-607434947):8)
com.google.android.gms.ads.internal.client.ay.getMobileAdsSettingManager (:com.google.android.gms@[email protected] (190400-607434947):12)
com.google.android.gms.ads.MobileAdsSettingManagerCreatorImpl.getMobileAdsSettingManager (:com.google.android.gms@[email protected] (190400-607434947):42)
com.google.android.gms.ads.internal.client.az.fL (:com.google.android.gms@[email protected] (190400-607434947):40)
obk.onTransact (:com.google.android.gms@[email protected] (190400-607434947):101)
android.os.Binder.transact (Binder.java:1173)
com.google.android.gms.internal.ads.zzavg.zzbh (com.google.android.gms:play-services-ads-base@@22.6.0:1)
com.google.android.gms.ads.internal.client.zzcp.zze (zzcp.java:169)
com.google.android.gms.ads.internal.client.zzeq.zza (zzeq.java:169)
com.google.android.gms.ads.internal.client.zzaq.zzc (com.google.android.gms:play-services-ads-lite@@22.6.0:169)
com.google.android.gms.ads.internal.client.zzax.zzf (com.google.android.gms:play-services-ads-lite@@22.6.0:126)
com.google.android.gms.ads.internal.client.zzax.zzd (com.google.android.gms:play-services-ads-lite@@22.6.0:126)
com.google.android.gms.ads.internal.client.zzej.zzA (com.google.android.gms:play-services-ads-lite@@22.6.0:17)
com.google.android.gms.ads.internal.client.zzej.zzm (zzej.java:53)
com.google.android.gms.ads.MobileAds.initialize (com.google.android.gms:play-services-ads-lite@@22.6.0:53)
com.MY_APP_PACKAGE.ads.AdMob.initAdmob (AdMob.kt:128)

Alguém tem esse problema?

Tenho outros aplicativos que usam a versão 22.6.0 do Admob e não percebi tais falhas neles e para este aplicativo isso aconteceu apenas para 6 usuários (de aproximadamente 230 mil usuários), mas ainda assim... por que isso poderia acontecer.

Atualizar :

Descobri que o mesmo problema acontece com outros: https://groups.google.com/g/google-admob-ads-sdk/c/88UHAaWElsc

Atualizado 2 :

Agora estou tendo mais travamentos e isso afeta outros aplicativos

ps também Admob Dashboard API caiu hoje, então mb é algo relacionado

Tópico Reddit

Rastreador de problemas do Google

Solução temporária : se você tiver o Firebase Remote Config configurado para seus aplicativos, desative anúncios, o que também evita chamadas MobileAds.initialize()se houver um parâmetro específico para isso que você adicionou. No meu caso infelizmente tenho parâmetros para ativar/desativar tipos de anúncios apenas nas telas dos meus aplicativos (banners, intersticiais), mas não tenho parâmetros para impedir o carregamento de informações de consentimento (biblioteca UMP) e MobileAds.initialize(), mas vou adicioná-los agora para o futuro casos...

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?

Eu li isso

Promoção integral: pré-valores de tipos integrais pequenos (como char) podem ser convertidos em pré-valores de tipos integrais maiores (como int). - primeira linha
[...detalhes - não importante...]
Observe que todas as outras conversões não são promoções; por exemplo, a resolução de sobrecarga escolhe char -> int (promoção) em vez de char -> short (conversão). - linha final.

A conversão de char -> int é 'promotion' ; está claro (de um byte para 4 bytes)
A ​​conversão de char -> short é 'não promoção'; por que?
Tenho pensado que char tem um byte e short (short int) tem dois bytes. Por que não é considerado uma promoção? Parece contradizer a primeira linha - não significa que 'converter do tipo pequeno para o tipo maior' é promoção? )
-----Editar: depois de procurar algumas respostas:
Podemos considerar "uma promoção é um caso especial de conversão"? , podemos dizer "todas as promoções são conversões, mas nem todas as conversões são promoções"?
Ou deveríamos considerá-los como dois conceitos diferentes e separados?

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.