einpoklum's questions

Estou escrevendo uma biblioteca C++, que trabalha com dados que têm alguns valores de tempo neles - valores que não se originam no sistema em que a biblioteca é executada. Quero colocar esses valores em std::chrono::time_point's (que serão expostos aos usuários da biblioteca).

Agora, para fazer isso, preciso especificar um Clocktipo. Ok, isso não deve ser um problema, certo? Posso atender a todos os requisitos de , não posso? ... hmm, não, não realmente, tenho um obstáculo: a now()função. Não posso fornecer um now()valor para o sistema onde os valores de ponto de tempo que estou olhando foram gerados! Não tenho acesso a ele, e talvez ele nem exista mais; e pode ter parado, ou sido reiniciado, ou deixado de existir completamente.

Isso significa que eu não devo usar std::chronotipos? Ou devo criar um tipo de relógio cuja now()função retorna um valor fictício fixo? Ou um valor artificialmente crescente?

Durante a execução de um processo, os resultados das chamadas subsequentes podem clGetPlatformIds()mudar? Ou seja, as plataformas podem desaparecer, aparecer, mudar de ordem ou mudar os identificadores ("ids")?

Estou perguntando sobre o que o padrão OpenCL garante, ou determina, é claro.

Em CUDA, iniciar um kernel significa especificar seus argumentos, organizados por meio de uma matriz de ponteiros:

CUresult cuLaunchKernel ( 
    CUfunction f, 
    /* launch config stuff */, 
    void** kernelParams,
    /* snip */ );

CUresult cuLaunchKernelEx ( 
    const CUlaunchConfig* config, 
    CUfunction f, 
    void** kernelParams, 
    /* snip */ ) ;

e após o lançamento - você ainda tem aquele conjunto de ponteiros para valores de argumentos, e você pode fazer o que quiser com ele: iniciar novamente, alterar e então iniciar etc.

No OpenCL, porém, os argumentos do kernel são definidos um por um e de forma opaca:

cl_int clSetKernelArg(
    cl_kernel kernel,
    cl_uint arg_index,
    size_t arg_size,
    const void* arg_value);

Então, você define, define, define algumas vezes, então inicia o kernel (usando clEnqueueNDRangeKernel()). O aspecto interessante disso é que cl_kernelnão representa apenas um pedaço de código executável do lado do dispositivo, mas sim um estado adicional, incluindo os argumentos que você definiu.

Minha pergunta é: Quais suposições posso fazer sobre esse estado e os argumentos que defini, após o lançamento de um kernel? Posso assumir que tudo está como estava antes do lançamento e posso alterar apenas alguns argumentos, mantendo o resto, para outro lançamento do mesmo kernel? Ou - eles são invalidados/perdidos de alguma forma e precisam ser totalmente definidos novamente? ... e talvez isso seja dependente da implementação?

Quero trabalhar de forma portável com tipos assinados de 64 bits em C. No entanto, sei que int64_tnão há garantia de que isso seja definido. Posso usar alguma mágica do pré-processador na geração do meu sistema de construção (por exemplo, CMake's check_type_size()) para obter definições do pré-processador me dizendo se posso usá-lo ou não. No entanto, temos o PRId64especificador de formato, que devemos usar para passar int64_tvalores para printf()funções semelhantes a . Posso, portanto, usar a definição de PRId64como um proxy para determinar se está ou não int64_tdisponível?

O CMake aparentemente já tem, há algum tempo, algo chamado "API de arquivo CMake" :

O CMake fornece uma API baseada em arquivo que os clientes podem usar para obter informações semânticas sobre os buildsystems que o CMake gera. Os clientes podem usar a API gravando arquivos de consulta em um local específico em uma árvore de build para solicitar zero ou mais Object Kinds. Quando o CMake gera o buildsystem nessa árvore de build, ele lê os arquivos de consulta e grava os arquivos de resposta para o cliente ler.

Não entendo quando e por quem isso deve ser usado. Consequentemente, não entendo se, como mantenedor de um projeto que emprega CMake, preciso me preocupar com essa API e "atender" às solicitações satisfatórias usando-a. Preciso?

Observação: se a resposta depender do tipo de projeto CMake que eu mantenho, escolha alguns exemplos (pois eu uso o CMake em mais de um tipo de projeto).

Suponha que eu tenha uma função que recebe alguns parâmetros de ponteiro - alguns não-const, através dos quais ela pode escrever, e alguns const através dos quais ela apenas lê. Exemplo:

void f(int * a, int const *b);

Suponha também que a função não escreva na memória (ou seja, não use variáveis ​​globais, endereços fixos, reformule os ponteiros const como não-const e truques do tipo).

Agora, é suficiente (de acordo com o padrão da linguagem C), para atingir os benefícios de restricttodas as leituras dentro de f(), apenas restrictos parâmetros de saída? Ou seja, no exemplo, restringir, amas não b?

Um teste simples (GodBolt) sugere que tal restrição deve ser suficiente. Esta fonte:

int f(int * restrict a, int const * b) {
    a[0] += b[0];
    return a[0] + b[0];
}

int all_restricted(int * restrict a, int const * restrict b) {
    a[0] += b[0];
    return a[0] + b[0];
}

int unrestricted(int * a, int const * b) {
    a[0] += b[0];
    return a[0] + b[0];
}

Produz o mesmo código objeto para x86_64:

f:
        mov     eax, DWORD PTR [rsi]
        mov     edx, DWORD PTR [rdi]
        add     edx, eax
        mov     DWORD PTR [rdi], edx
        add     eax, edx
        ret
all_restricted:
        mov     eax, DWORD PTR [rsi]
        mov     edx, DWORD PTR [rdi]
        add     edx, eax
        mov     DWORD PTR [rdi], edx
        add     eax, edx
        ret
unrestricted:
        mov     eax, DWORD PTR [rsi]
        add     eax, DWORD PTR [rdi]
        mov     DWORD PTR [rdi], eax
        add     eax, DWORD PTR [rsi]
        ret

mas isso não é uma garantia geral.

Motivação

Parâmetros de array podem ser alias uns dos outros, e o compilador deve cuidadosamente permitir essa possibilidade. Assim, por exemplo:GodBolt

int foo(int a[10], int b[10]) {
    a[0] += b[0];
    return a[0] + b[0];
}

int bar(int *a, int *b) {
    a[0] += b[0];
    return a[0] + b[0];
}

int baz(int * __restrict a, int * __restrict b) {
    a[0] += b[0];
    return a[0] + b[0];
}

o código compilado para foo()deve ser como o de bar(), não como o de baz().

Pergunta

Quero usar parâmetros de array para minha função - possivelmente até arrays multidimensionais (não arrays-de-ponteiros; o tipo que você declara com um par de colchetes e decai para ponteiros simples de um nível para o primeiro elemento). E também quero que o compilador assuma que não há aliasing, ou seja, quero marcar meus parâmetros de array como restrict'ed.

Como posso fazer isso em C? E se não posso, por que?

Ao marcar um construtor como excluído, ou seja

class MyClass {

   // ... 

   MyClass(int x) = delete;

   // ... 

};

existe algum efeito em marcar o construtor excluído como explicit? ou seja

   explicit MyClass(int x) = delete;

?

Estou usando o MSVC 16 2019 com muitos avisos ativados, incluindo C4127: a expressão condicional é constante. No entanto, tenho um código que se parece com:

template <bool B>
void foo(int x) {
    if (B && x == 0) { do_stuff(); }
    do_other_stuff();
}

... e o aviso é acionado quando B é falso.

Quero manter esse erro em geral, mas não quero que ele avise gratuitamente quando a constância da expressão de condição for devida apenas à instanciação do modelo.

Nota: Esta questão está relacionada, mas - o código não vai mudar (significativamente), então não é isso que estou perguntando. Também não em C++ 17.

Considere este trecho de código (adaptado de cppreference.com):

constexpr std::string_view text{"Hello-+-C++-+-23-+-!"};
constexpr std::string_view delim{"-+-"};
std::ranges::for_each(text | std::views::lazy_split(delim), act_on_substring);

Quero fazer o mesmo para um fluxo - digamos, std::cin- em vez de text. Eu tentei:

auto isv = std::views::istream<std::string>(std::cin);
constexpr std::string_view delim{"-+-"};
std::ranges::for_each(isv | std::views::lazy_split(delim), act_on_substring);

Mas este código não consegue compilar :

<source>:21:31: error: invalid operands to binary expression ('basic_istream_view<basic_string<char, char_traits<char>, allocator<char>>, char, char_traits<char>>' and '_Partial<_LazySplit, decay_t<const basic_string_view<char, char_traits<char>> &>>' (aka '_Partial<std::ranges::views::_LazySplit, std::basic_string_view<char, std::char_traits<char>>>'))
   21 |     std::ranges::for_each(isv | std::views::lazy_split(delim), act_on_substring);
      |                           ~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

por que?