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);
}
myUnion_tdefinido como é aqui?intvalUB?Nenhum dos compiladores testados emite aviso (compilados também com compiladores C++)
A duplicata está relacionada apenas à pergunta 2, não à principal.
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.
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.
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?
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?
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++.
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?
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
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?
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.
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)
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.