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;
}

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

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));
        }
    }
}

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