No código a seguir:

struct copy_only
{
    copy_only() = default;
    copy_only(const copy_only&)            = default;
    copy_only& operator=(const copy_only&) = default;
    copy_only(copy_only&&)                 = delete;
    copy_only& operator=(copy_only&&)      = delete;
    ~copy_only()                           = default;
};


std::vector<copy_only> v;
copy_only c{};
v.push_back(c);

No MSVC obtemos o erro:

erro C2280: 'copy_only::copy_only(copy_only &&)': tentativa de referenciar uma função excluída

Isso vem de dentro da implementação do vetor, onde push_back(const&)chama emplace_backa implementação:

nota: ao compilar a função de membro do modelo de classe 'void std::vector<copy_only,std::allocator<copy_only>>::push_back(const _Ty &)'

nota: veja a referência à instanciação do modelo de função '_Ty &std::vector<_Ty,std::allocator<_Ty>>::_Emplace_one_at_back<const _Ty&>(const _Ty &)' sendo compilado

Isso compila com gcc e clang. Será que isso é apenas um bug enorme do compilador MSVC no exemplo de vetor mais simples? Ou existe algum padrão que impeça esse uso, algo que o gcc e o clang estão apenas ignorando?

Exemplo vivo.

Considerando um ano, mês e dia, como encontro o próximo dia da semana nessa data ou depois? Por exemplo, se eu tiver 28/04/2025, como encontro a sexta-feira seguinte a 28/04/2025, que é 02/05/2025?

Que tal encontrar o dia da semana anterior em vez do próximo?

Posso começar com intvalores, colocá-los chronoe depois retirá int -los?

Se a data de entrada já estiver no dia da semana de destino, o que é necessário para alterar entre obter a data de entrada ou obter uma semana a partir da data de entrada?

É legal escrever algo assim?

#include <memory>

struct A {
    int i, j;
    constexpr A() : i((std::construct_at(&j, 2), j-1)) {}
};
constexpr A a{};
static_assert(a.i == 1);
static_assert(a.j == 2);

Aqui, io inicializador -member primeiro inicializa jo membro usando std::construct_ate depois lê seu valor em j-1.

Na prática, vejo que todos os GCC, MSVC e Clang aceitam o programa. Demonstração online: https://gcc.godbolt.org/z/YzEoPPj96

Mas Clang emite o aviso:

<source>:5:50: warning: field 'j' is uninitialized when used here [-Wuninitialized]
    5 |     constexpr A() : i((std::construct_at(&j, 2), j-1)) {}
      |                                                  ^

Isso parece contraditório, já que a leitura de valores não inicializados em expressões constantes deve resultar em falha grave. O programa está bem formado e o diagnóstico está simplesmente errado?

E graças ao @TedLyngmo, aqui está um exemplo mais complicado com alocações de heap:

#include <string>

struct A {
    std::string i, j;

    constexpr A()
        : i(((void)std::construct_at(&j,
                                     "Hello world, this is very funny indeed "
                                     "and this is a long string"),
             j + " with some exta in it"))
        , j([k=std::move(j)]()mutable { return std::move(k); }()) {}
};

static_assert( A{}.i.length() == 85 );
static_assert( A{}.j.length() == 64 );

Demonstração online: https://gcc.godbolt.org/z/zcb4hbhY3

Estou encontrando uma diferença inesperada no comportamento entre o SFINAE tradicional (usando type_traitsand std::void_t) e os conceitos modernos do C++20 ao definir um fallback genérico operator<<. O propósito é direto: criar um genérico operator<<que seja habilitado somente se nenhuma definição personalizada existente operator<<for encontrada via Argument-Dependent Lookup (ADL) .

A detecção baseada em SFINAE da velha escola usando características ( is_std_streamable) funciona como esperado, definido como:

template <class T, class = void>
struct is_std_streamable : std::false_type {};

template <class T>
struct is_std_streamable<T, std::void_t<decltype(std::declval<std::ostream&>() << std::declval<const T&>())>> : std::true_type {};

E a detecção baseada em conceitosStdStreamable ( ) é definida como:

template <class T>
concept StdStreamable = requires(const T t, std::ostream& os) {
    { os << t } -> std::same_as<std::ostream&>;
};

O fallback genérico operator<<se parece com isto ( requirescláusulas comentadas):

template <StdPrintable T>
// requires(!StdStreamable<T>)
// requires(!is_std_streamable<T>::value)
std::enable_if_t<!is_std_streamable<T>::value, std::ostream&>
operator<<(std::ostream& os, T const& val) {
...
}

Ao descomentar a cláusula baseada em conceitos ( ou ), tanto o GCC quanto o Clang produzem o seguinte erro de restrição cíclica:requiresrequires(!StdStreamable<T>)requires(!is_std_streamable<T>::value)

error: satisfaction of constraint 'StdStreamable<T>' depends on itself

Entendo que usar a std::declval<std::ostream&>() << std::declval<const T&>()expressão em uma requirescláusula ao definir uma nova versão de operator<<pode ser interpretado pelo compilador como uma dependência cíclica. Mas por que os conceitos do C++20 acionam esse problema de restrição cíclica, enquanto o SFINAE tradicional não? Esse comportamento é obrigatório pelo padrão, uma limitação conhecida de conceitos ou potencialmente um bug do compilador?

Exemplo mínimo reproduzível completo e detalhes adicionais:

• https://godbolt.org/z/be7Yqxo93

Desde já, obrigado.

Contexto:

Em C++, é possível criar uma referência a uma "matriz de limites desconhecidos".

Exemplo:const char (&)[]

Antes do C++20, o clang (14.x, 18.x) não permitia que você coagisse uma referência a uma matriz de limites conhecidos para uma referência a uma matriz de limites desconhecidos e falharia com um erro:

referência ao tipo incompleto 'const char[]' não pôde ser vinculada a um lvalue do tipo 'const char[5]'

Para C++20, o clang agora permite isso.

O gcc, por outro lado, sempre permitiu isso, desde o C++98.

Questões:

• Isto é apenas uma discordância sobre padrões?
• Algum deles estava errado?
• O C++20 mudou ou esclareceu o padrão que torna isso mais claramente válido?

Exemplo

https://godbolt.org/z/66sh8a5z1

int main() {
    using StringLitRef = const char (&)[];
    StringLitRef array = "derp"; // works on g++ for any standard and clang with c++20
    return 0;
}

"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.

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')

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?

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?

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?

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?

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.