All perguntas(coding)

Descobri por acidente, ao modificar o código existente, que uma declaração de alias foi criada std::optional<void>. Veio de um código de modelo como este:

using ret_t = std::invoke_result_t<Fn, Args...>;
using opt_ret_t = std::optional<ret_t>;

Posteriormente, o código discrimina o caso quando o tipo de retorno é (not) void, portanto, nunca há realmente um optionalobjeto criado.

Para ter certeza de que não estava faltando nada, adicionei uma afirmação nesse ramo do código e tudo compila:

static_assert(std::is_same_v<opt_ret_t, std::optional<void>>);

cppreference diz :

Não há referências opcionais, funções, arrays ou cv void; um programa está mal formado se instanciar um opcional com esse tipo.

Portanto, independentemente dos compiladores não reclamarem, esse código está mal formado?

template <typename... Ts>
struct A
{
    template <typename C>
    constexpr auto proc() noexcept { return C{ }; }
    constexpr size_t size() noexcept { return sizeof...(Ts); }
};

template <typename... Ts>
struct B : public A<Ts...>
{
    using base_t = A<Ts...>;

    template <typename... Cs>
    constexpr auto example_prog_1() noexcept
    {
        constexpr size_t tmp = base_t::size();
        // error C2131 : its not constexpr
        return tmp + sizeof...(Cs);
    }

    template <typename... Cs>
    constexpr auto example_prog_0() noexcept
    {
        return example_prog_1<decltype(base_t::template proc<Cs>())...>();
    }
};

int main()
{
    B<int, int, int, int> obj0 { };
    constexpr size_t result0 = obj0.example_prog_0<char, char, char, char>();
}

isso não funciona. recebi o erro C2131: a expressão não foi avaliada como uma constante.

    template <typename... Cs>
    constexpr auto example_prog_1() noexcept
    {
        B dup{ };
        constexpr size_t tmp = dup.size();
        // error none  : its fine
        return tmp + sizeof...(Cs);
    }

mas fazer uma cópia está bem.

também funciona ao adicionar 'this auto self' e usá-lo.

alguém poderia me dizer por quê? (msvc /std:c++mais recente)

Atualmente estou desenvolvendo um sistema ERP (Enterprise Resource Planning) e preciso tomar decisões quanto ao tipo de dados a serem usados ​​para lidar com cálculos e outros valores numéricos dentro da aplicação.

Eu sei que Java oferece diversas opções para lidar com números decimais, como BigDecimal e Double. Entendo que cada um tem suas vantagens e desvantagens, mas quero garantir que escolho o mais adequado para manter a precisão e a eficiência em meu sistema.

Aqui estão alguns contextos específicos onde preciso aplicar cálculos:

• Faturamento e Pagamentos: lidar com preços, impostos, descontos, etc.
• Folha de pagamento e contabilidade:
• Gestão de estoque: Incluindo preços unitários e custos de produtos.

Estou inclinado a usar o BigDecimal para operações financeiras devido à precisão que oferece, mas estou preocupado com o impacto no desempenho. Por outro lado, Double pode ser mais eficiente em termos de velocidade, mas pode introduzir erros de arredondamento.

Que recomendações você tem para lidar com esses casos em um ERP? Em quais situações seria preferível usar BigDecimal e quando Double? Existem padrões ou práticas recomendadas que devo seguir?

Tenho cerca de 75.000 arquivos e preciso pesquisar em cada arquivo um conjunto de frases-chave armazenadas em uma matriz. Tenho Intel i9 capaz de executar 20 threads. Estou tentando acelerar todo o processo, agrupando cada arquivo em uma string e combinando cada frase-chave simultaneamente. Eu me pergunto como posso usar o hyper/race para agilizar ainda mais o processo. Ou as junções distribuem automática e simultaneamente as tarefas entre os threads?

[1] > my $a = (1..10).join
12345678910
[3] > my @b = (3, /5./, /8\d/)
[3 /5./ /8\d/]
[4] > say $a.match( @b.all )
all(3, 56, 89)

[4] > say hyper $a.match( @b.all )
No such method 'hyper' for invocant of type 'Match'.    # what to do?

Conforme mostrado aqui , o comportamento de allocate(0)não é especificado.

Então, o que acontecerá se eu chamar allocate_at_least(0)de acordo com o padrão C++23? O comportamento é definido pela implementação ou será tratado como allocate(a_non_zero_value)?

work = pd.DataFrame({"JOB" : ['JOB01', 'JOB01', 'JOB02', 'JOB02', 'JOB03', 'JOB03'],
"STATUS" : ['ON_ORDER', 'ACTIVE','TO_BE_ALLOCATED', 'ON_ORDER', 'ACTIVE','TO_BE_ALLOCATED'],
"PART" : ['PART01', 'PART02','PART03','PART04','PART05','PART06']})

Como posso usar o Pandas para agrupar o JOB, dividir o Status em colunas com base nos valores e concatenar o campo Parte com base no JOB.

Saída desejada:

JOB    | ON_ORDER  | ACTIVE   | TO_BE_ALLOCATED | PART_CON
JOB01  | True      | True     | False           | Part01\nPart02
JOB02  | True      | False    | True            | Part03\nPart04
JOB03  | False     | True     | True            | Part05\nPart06

Este código funciona em GCC e Clang, bug não em MSVC:

#include <concepts>
#include <utility>

struct S {};

const S&& f();
S g();

static_assert(std::same_as<decltype(false ? f() : g()), const S>);

https://godbolt.org/z/99rMPzecM

MSVC pensa decltype(false ? f() : g())que éconst S&&

Qual deles está certo? E porque?

Eu tenho um arquivo CSV grande sem uma linha de cabeçalho e o cabeçalho está disponível como um vetor. Quero usar um subconjunto das colunas do arquivo sem carregar o arquivo inteiro. O subconjunto de colunas necessárias é fornecido como uma lista separada.

Editar: neste caso, os nomes das colunas fornecidos na lista de cabeçalho são importantes. Este MRE possui apenas 4 nomes de colunas, mas a solução deve funcionar para um grande conjunto de dados com nomes de colunas pré-especificados. O problema é que os nomes das colunas são fornecidos apenas externamente, não como um cabeçalho no arquivo CSV.

1,2,3,4
5,6,7,8
9,10,11,12

header <- c("A", "B", "C", "D")
subset <- c("D", "B")

Até agora, tenho lido os dados da seguinte maneira, o que me dá o resultado desejado, mas carrego o arquivo inteiro primeiro.

# Setup

library(readr)

write.table(
  structure(list(V1 = c(1L, 5L, 9L), V2 = c(2L, 6L, 10L), V3 = c(3L, 7L, 11L), V4 = c(4L, 8L, 12L)), class = "data.frame", row.names = c(NA, -3L)),
  file="sample-data.csv",
  row.names=FALSE,
  col.names=FALSE,
  sep=","
)

header <- c("A", "B", "C", "D")
subset <- c("D", "B")

# Current approach

df1 <- read_csv(
  "sample-data.csv",
  col_names = header
)[subset]

df1

# A tibble: 3 × 2
      D     B
  <dbl> <dbl>
1     4     2
2     8     6
3    12    10

Como posso obter o mesmo resultado sem carregar primeiro o arquivo inteiro?

Perguntas relacionadas

• Somente a leitura de colunas selecionadas inclui o cabeçalho na primeira linha.
• Maneiras de ler apenas colunas selecionadas de um arquivo em R? (Um meio-termo entre read.tablee scan?) [duplicado] não especifica nomes de colunas fora do arquivo e as respostas não se aplicam a esta situação.
• como pular a leitura de certas colunas em readr [duplicado] é diferente porque parece ser sobre pular uma primeira coluna desconhecida e ler uma segunda e terceira colunas conhecidas em vários arquivos. Os tipos de dados não são necessariamente conhecidos antecipadamente nesta questão.
• Existe uma maneira de omitir a primeira coluna ao ler um csv [duplicado] : a coluna é ignorada com base na posição, não na posição em uma lista fornecida externamente de nomes de colunas.

Tenho as duas perguntas a seguir: (1) Quero que o rótulo fique entre dois ticks. Meu pensamento original era adicionar os ticks secundários e remover os ticks primários, mas axis.minor.ticks.length.y não funciona (2) Adicione pontos stat_summary na legenda Muito obrigado por responder suas perguntas!

Aqui está o código e a figura:

library("ggplot2")
dt <- data.frame(
  ca = rep(c("Oesophageal cancer", "Gastric cancer", "Colorectal cancer"), 3),
  var1 = c(1:3, -4:-6, 7:9),
  var2 = rep(LETTERS[1:3], 3)
)

dt %>% 
  ggplot(aes(var1, ca, fill = var2))+
  geom_bar(stat="identity", width=0.8)+
  stat_summary(fun=sum, geom="point",colour="grey40", fill="grey40", shape=20, size=2)+
  geom_vline(xintercept=0, colour="grey30", linetype="dotted")+
  theme(
    axis.minor.ticks.length.y = rel(0.5)
  )

Objetivo: Alterar o estilo da Figura 1 para a Figura 2

Qual é a melhor maneira de lidar com uma CALL em assembly x64, que deve retornar para um endereço de retorno ligeiramente alterado? Principalmente no que diz respeito à eficiência/velocidade de execução. Vou explicar brevemente o que estou tentando fazer.

Fundo

Eu tenho uma linguagem de script visual interpretada e personalizada, que é compilada em código nativo. Esta linguagem possui corrotinas baseadas em pilha integradas e, anteriormente, elas ainda eram tratadas semi-interpretadas (com uma classe de pilha separada para armazenar os dados da corrotina). Estou no processo de nativizá-lo totalmente, para que apenas o RSP seja usado.

Uma parte dessas corrotinas é a capacidade de rendimento aninhado, ou seja, se uma corrotina chamar outro método de rendimento, esse método pode render internamente para suspender toda a invocação. Essas informações são tratadas por meio de uma estrutura "YieldState", armazenada em um registro. Isso significa que, para a nova variante totalmente nativa, podemos apenas chamar um método de rendimento de uma corrotina com uma instrução de chamada:

call      12345; // [rip+12345] => yieldingMethod

Pelo menos, em teoria. Como nossas corrotinas são baseadas em pilha, armazenamos variáveis ​​locais claramente na pilha, e não em algum tipo de classe como as corrotinas sem pilha fariam. Isso requer que a limpeza (caso a corrotina seja destruída antes de terminar) seja feita por meio de outro método, que chamei de "manipulador de interrupção". A invocação desse manipulador de interrupção é bastante comum em meu caso de uso prático, mas não excessivamente. Portanto, meu objetivo era fornecer algo que fosse mais rápido que um manipulador de exceções (que geralmente requer alguma pesquisa global do quadro), mas não exigisse a configuração explícita desse endereço para cada chamada. Então o que fiz foi incorporar o endereço do manipulador de interrupção entre a chamada e o endereço de retorno - como para a versão antiga do código tínhamos que carregar o retorno manualmente, isso não era um problema:

lea rcx,[rip+25]; // 25 is the assumed byte-size up until the return address
mov rdx,rbx;      // load non-native call stack
call prepareMethodYielding; // stores return-address on stack
jmp 12345;        // actually call our "yieldingMethod"
mov r15,interruptAddress;

A última instrução nunca é executada - deixamos o endereço de retorno para ignorá-la. Só o temos aqui para poder consultar o manipulador de interrupções. Dado um endereço de currículo, podemos simplesmente diminuir o ponteiro em 8 e temos o endereço dessa interrupção de currículo. O "mov r15" no nosso caso serve apenas para nos permitir desmontar o código corretamente; poderíamos simplesmente incorporar o endereço sozinho, mas isso confundiria qualquer desmontador externo.

O problema real

Agora, na nova versão, não há "prepareMethodYielding", mas apenas uma chamada - pelo menos, de forma ideal. Mas a "ligação" por si só não nos permite fazer um endereço de retorno modificado, então aqui me deparo com algumas opções e quero saber qual é a melhor.

Opção A - lea + push + jmp

Nossa primeira opção é simular a "chamada", mas enviar o endereço de retorno manualmente:

lea         rax,[rip+10h]
push        rax
jmp         A6 // yieldingMethod

Isto requer 3 instruções, mas nenhum acesso à memória.

Opção B - enviar da memória

Poderíamos reduzir o número de opções armazenando o endereço de retorno em alguma área da memória constante:

push        qword ptr[rip+1234] // return-address stored here
jmp         A6                  // yieldingMethod

Agora precisamos apenas de um push e nenhum registro intermediário, embora agora precisemos de acesso à memória, que poderia estar potencialmente mais distante na seção de dados.

Opção C – modificar o endereço de retorno na função chamada

Outra opção que vejo seria ajustar o endereço de retorno produzido pela chamada dentro do método chamado. Todos esses métodos aqui são compilados usando minha própria convenção de chamada, portanto, não aderem ao x64 ou a qualquer outro.

// caller
call     A6                 // yielding method

// callee, first instruction
add      qword ptr[rsp],10  // size of interrupt-embedding is always the same

Também seria apenas uma instrução, com uma pequena codificação. Embora apenas do ponto de vista do design, eu não goste muito disso, pois acopla as informações sobre a incorporação do receptor ao chamador - embora, se essa fosse a variante mais eficiente, eu ainda poderia optar por ela.

Opção D - não modifique o endereço de retorno

Nossa última opção é não modificar o endereço de retorno, mas sim alterar a forma como a pesquisa e o retorno são tratados.

call      12345;                // yieldingMethod
mov       r15,interruptAddress; // is actually executed now (but value is not used)

Então aqui, mudaríamos onde procuramos o endereço de interrupção (já que o endereço de retorno agora aponta na frente da instrução falsa, em vez de atrás dela). Então, ao retornar da chamada, executaríamos a instrução movebs, mas descartaríamos o valor carregado. A vantagem aqui é que o tamanho geral do código é o menor, já que não precisamos adicionar instruções adicionais que ainda não estejam lá. No entanto, estamos executando uma instrução mov de 10 bytes, que pode ser mais lenta do que algumas das outras variantes. Depende aqui do que a CPU está fazendo - se ela já decodifica a instrução falsa, mesmo que não a alcance diretamente, pode ser a melhor ideia apenas executá-la, em vez de modificar o endereço de retorno. A mesma coisa, se a CPU puder de alguma forma detectar que a instrução não tem efeito, já que seu valor nunca é lido, durante a renomeação de registros, então ele poderia ser efetivamente gratuito - atm, estou usando um registro que não é usado, para distinguir meu próprio montador; mas provavelmente faria sentido usar um registro que fosse sobrescrito logo depois, presumo. Embora eu não tenha certeza do que realmente aconteceria aqui.

Conclusão

Então, qual dessas 4 opções lhe parece mais eficiente? Também estou aberto a outras idéias, embora o design geral de como as corrotinas são feitas seja finalizado e funcional, então algo como usar uma abordagem baseada em máquina de estados que algumas corrotinas do IIRC usam não é realmente uma opção aqui.