ABu's questions

O seguinte trecho de código falha com o gcc 8.5 até 10.5 com g++ -std=c++17( https://godbolt.org/z/od99f93Tx ):

struct T { char arr[2]; };

int main()
{
    T data;
    data = { "V" };
    return 0;
}

O erro é:

source>: In function 'int main()':
<source>:6:18: error: no match for 'operator=' (operand types are 'T' and '<brace-enclosed initializer list>')
     data = { "V" };
                  ^
<source>:1:8: note: candidate: constexpr T& T::operator=(const T&)
 struct T { char arr[2]; };
        ^
<source>:1:8: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'const T&'
<source>:1:8: note: candidate: constexpr T& T::operator=(T&&)
<source>:1:8: note:   no known conversion for argument 1 from '<brace-enclosed initializer list>' to 'T&&'
Compiler returned: 1

Mas funciona no gcc 11.1 com o mesmo -std=c++17sinalizador. Se você alterar o membro do array para algum outro tipo não array (como int ou qualquer outro), e substituir "V"por algum valor compatível, é claro, funciona em todas as versões de 8.5 a 11. Foi um bug do gcc que foi corrigido no gcc 11, ou melhor, algum defeito padrão relacionado à inicialização agregada que não foi resolvido até mais tarde? Ou o quê?

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.

No AWK, para ordenar um array, posso definir minha própria função de ordenação, tanto para controlar a travessia de um array em um loop for, quanto para chamar asortor asorti. A assinatura da função de comparação aceita até 6 parâmetros, embora os dois últimos sejam opcionais:

function cmp_field(i1, v1, i2, v2, l, r) { whatever; }

Qual é o propósito de le r? Pelo que entendi, eles são apenas marcadores de posição que não são usados ​​ou inspecionados pelo AWK, mas sim uma conveniência para mim, para que eu possa armazenar valores dentro deles, como algum tipo de variáveis ​​auxiliares de conveniência. Como atribuir em le rvalores temporários calculados de v1e v2. No entanto, por que preciso deles ou qual é o propósito deles, se eu posso simplesmente declarar minhas próprias variáveis ​​como:

function cmp_field(i1, v1, i2, v2) { 
   l = computation(v1);
   r = computation(v2);
   whatever; 
}

Existe alguma outra diferença além de le rsendo variáveis ​​globais no segundo exemplo? Ou existe alguma outra razão além disso?

Pelo que entendi:

• Livelock: um thread não progride, mas continua em execução para sempre (o thread está infinitamente ativo): por exemplo, ele está em um loop infinitamente tentando obter acesso a um recurso compartilhado que nunca estará disponível novamente.
• Deadlock: uma thread não progride, mas nem sequer está em execução (a thread está infinitamente adormecida e, portanto, morta): ela está esperando ser despertada pelo sistema operacional com base em uma condição que nunca acontecerá.
• Fome: uma thread não progride e está bloqueando (como em um deadlock), mas a condição que está sendo aguardada para ser despertada ocorre, acontece que há outras threads que sempre tomam meu lugar antes de mim.

Primeiro, essas definições estão mais ou menos corretas? Se estiverem, elas também se aplicam a programas single thread? Por exemplo:

// begin of useful work
until (some_buggy_condition_that_will_never_be_satisfied())
    do_something();
// end of useful work

No exemplo acima, o loop será executado para sempre porque a condição, que não tem nada a ver com recursos compartilhados, tem um bug e nunca será satisfeita. Então o thread:

• Está em execução.
• Para fazer um trabalho útil o loop deve terminar
• O loop nunca terminará porque a condição para terminar nunca será satisfeita

Então essa lista corresponde à minha definição de livelock acima, só que estou usando o termo fora dos contextos de simultaneidade. Tudo bem?

Imagine a seguinte situação, onde eu tenho uma noexceptfunção livre em C++ que é passada como um ponteiro de função para outra função com ligação C:

extern "C" {
   void some_fun(void(*)());
}

void my_fun() noexcept { /* do stuff */; }

int main()
{
   some_fun(my_fun);
}

Isso está correto e/ou é permitido? O que acontece nesse caso? Qual é a semântica aqui considerando que C++17 noexceptpertence ao tipo de uma função?

Além disso, e para minha surpresa, isso ainda compila (com gcc e clang):

extern "C" {
   void some_fun(void(*)() noexcept);
}

void my_fun() noexcept { /* do stuff */; }

int main()
{
   some_fun(my_fun);
}

Faz sentido que um ponteiro de função na assinatura de uma função C permita o qualificador noexceptnela?

Quero criar uma função cleartal que, ao chamá-la assim clear(v), substitua vpor um valor construído padrão do mesmo tipo (que é uma inicialização zero para tipos internos). A solução mais simples v = {}não funciona para arrays porque você não pode atribuir a ela, e então acabo fazendo isso:

    template<class T>
    void clear(T& v) noexcept
    {
        if constexpr (std::is_array_v<T>) {
            using base_t = std::remove_all_extents_t<T>;

            if constexpr (std::is_trivially_default_constructible_v<base_t>)
                std::memset(v, 0, sizeof(v));
            else {
                // To deal with multidimensional arrays, I make sure to get pointers
                // the first and last actual value of the array.
                base_t* it = reinterpret_cast<base_t*>(v);
                base_t* end = it + sizeof(v) / sizeof(base_t);

                for (; it != end; ++it)
                    clear(*it);
            }
        } else
            v = {};
    }

Gostaria de saber sobre potenciais armadilhas sobre essa implementação, especificamente em relação a regras de aliasing e alinhamento. Acho que a implementação está OK, mas não tenho certeza. A verificação para o tipo base do construtor trivial é porque tenho que ter certeza de que o construtor padrão do tipo não adiciona valores de inicialização personalizados para seu membro na lista de inicialização ou por meio de um inicializador padrão. Em outras palavras, que para esse tipo inicializá-lo com zero e inicializá-lo com valor padrão são sinônimos.

Mas a implementação parece muito mais complicada do que deveria, e também prefiro que o compilador cuide de tudo isso. Só quero consertar o problema de arrays não serem atribuíveis, então acabei fazendo isso:

    template<class T>
    void clear(T& v) noexcept
    {
        struct helper { T v; };
        *reinterpret_cast<helper*>(&v) = {};
    }

e quero saber também sobre as potenciais armadilhas dessa abordagem.

Eu tenho um repositório git com um histórico local linear de, digamos, 10 commits, onde os primeiros 5 estão no branch1histórico de e os últimos 5 commits estão no branch2histórico de e quero corrigir as descrições/autor/data /other propriedades desses dez commits, alterando-os. A situação seria assim:

---(old history)---A--B--C--D--E--F--G--H--I--J
                               ^              ^
                               |              |
                            branch1       branch2

Não tenho certeza sobre como proceder aqui. Posso pensar em duas estratégias para fazer o que quero, mas quero primeiro compreender seus efeitos potenciais.

1. em vez de fazer um rebase interativo mais longo de 10 commits, prefiro mudar para branch1primeiro, fazer um rebase interativo nos últimos 5 commits e, quando terminar, mudar branch2e fazer um rebase interativo dos últimos 5 commits. Mas como o rebase implica na criação de novos commits em um "novo branch", não sei o que aconteceria com o pai do HEAD do branch1. A questão é : essa estratégia criará algum tipo de estado estranho como este (vamos chamar branch1'o novo branch após o rebase):

   ---(old history)---?--?--?--?--?--F--G--H--I--J
                    |             ^              ^
                    |             |              |
                    |          branch1(???)    branch2(???)
                    |
                    |
                    --A--B--C--D--E
                                  ^
                                  |
                               branch1'
   

   ou o git consertará o pai Fda maneira certa?

2. A outra estratégia é mudar branch2e fazer um rebase interativo dos seus últimos 10 commits diretamente; mas, novamente, a questão é : para onde o HEAD branch1apontará depois do rebase? Para um commit que não está mais na branch2história?

Em um arquivo Pro*C, tenho um bloco PL/SQL anônimo muito simples como este:

EXEC SQL BEGIN DECLARE SECTION;
     unsigned long long stuff = 0;
EXEC SQL END DECLARE SECTION;

EXEC SQL EXECUTE
DECLARE
    nrows pls_integer := 0;
BEGIN
    select count(*) into nrows from tbl;

    if nrows != 1 then
        RAISE_APPLICATION_ERROR(-20000,
                    'The table must contain exactly one row');
    else
        select stuff into :stuff FROM tbl;
    end if;
END; 
END-EXEC;

Protestos Pro*C com:

CSF-S-00201, identifier 'RAISE_APPLICATION_ERROR' must be declared

No entanto, movendo o bloco PL/SQL anônimo para o desenvolvedor SQL (e adicionando uma variável stuff):

VARIABLE stuff NUMBER;

DECLARE
    nrows pls_integer := 0;
BEGIN
    select count(*) into nrows from tbl;

    if nrows != 1 then
        RAISE_APPLICATION_ERROR(-20000,
                    'The table must contain exactly one row');
    else
        select stuff into :stuff FROM tbl;
    end if;
END;
/

funciona bem. O que poderia estar acontecendo? O esquema que estou usando para compilar o arquivo Pro*C e executar o bloco no SQL Developer é o mesmo.

Eu configurei as seguintes opções:

sqlcheck=semantics
parse=partial
code=cpp
common_parser=yes

sqlcheck=semanticsé obrigatório se o arquivo contiver blocos PL/SQL, tentei remover, common_parser=yesmas o erro é o mesmo e não consigo remover parse=partialand code=cpp, mas não acho que isso afetaria de forma alguma.

Vamos imaginar que tenho uma linha de compilação como a seguinte:

gcc <flags...> -o a.out obj1.o obj2.o

onde ambos obj1.oe obj2.odefinem void f(int). Receberei um erro de definição múltipla (violação da regra de definição única).

Ok, agora imagine o seguinte:

gcc <flags...> -o a.out obj1.o -lstatic_lib

onde ambos obj1.oe static_lib.adefinem f(int). Eu sei que uma biblioteca estática é uma concatenação de .oarquivos, e para cada símbolo pendente de ser resolvido, for encontrado dentro de qualquer um dos .oarquivos da biblioteca estática, então o todo .o que resolver aquele símbolo será vinculado ao binário, junto com qualquer outro símbolo que o mesmo .ofornece.

Esse comportamento me faz pensar. Imagine que static_lib.aé composto por dois objetos, static_obj1.oe static_obj2.o, onde static_obj1.oé quem define f(int). Como obj1.ojá define f(int)também, o vinculador não está procurando por ele dentro static_lib.ae, portanto, static_obj1.onão será incluído teoricamente, mas, e esta é a questão:

• E se obj2.oexigir f2(int), quem também é definido por static_obj1.o? O vinculador, após a integração static_obj1.opor causa de f2(int), emitiria um aviso de definição múltipla por f1(int)ser agora duas vezes?

NOTA: estou marcando C e C++ porque acho que o comportamento é o mesmo para ambos nesse aspecto. Caso contrário, esclareça, estou muito interessado em saber alguma diferença comportamental. Além disso, se o comportamento for muito diferente entre gcc/clang/visual studio/linux/windows, esclareça. Se o comportamento for praticamente o mesmo, concentre-se no gcc em vez do linux.

Nos arquivos que estão sendo compilados usando o gcc (vários arquivos .c e .cpp), tenho atualmente algo como:

#if defined(__GNUC__) && !defined(__clang__)
    #pragma GCC diagnostic warning "-Wall"
#endif

O objetivo de especificar opções inline em vez de apenas usar a linha de comando é controlar após quais pontos é interessante ser mais rigoroso (por exemplo, após a #includelista).

Funciona bem. Tentei então adicionar -Wextracom:

#if defined(__GNUC__) && !defined(__clang__)
    #pragma GCC diagnostic warning "-Wall -Wextra"
#endif

Falha. Aparentemente, você não pode usar mais de uma opção em um único pragmae, em vez disso, deve usar várias linhas:

#if defined(__GNUC__) && !defined(__clang__)
    #pragma GCC diagnostic warning "-Wall"
    #pragma GCC diagnostic warning "-Wextra"
#endif

• Q1: Existe uma maneira de especificar várias opções em linha?

Em seguida, tentei adicionar -Werrorand -pedantic, e nem usando diagnostic warningnem diagnostic errorfunciona. Exemplo:

    #pragma GCC diagnostic error "-Werror"

falha com: warning: ‘-Werror’ is not an option that controls warnings. Como posso resolver isso? quais outras alternativas existem além diagnostic [warning|error]? E quanto a -pedanticou -pedantic-errors? Porque sei que o pedante está mais relacionado à conformidade com os padrões do que ao controle de diagnóstico e não sei se posso especificá-lo in-line.

Um intervalo direto rrequer que seu iterador seja, por sua vez, um iterador direto, o que, por sua vez, exige que o iterador funcione como seu próprio sentinela. Mas isso implica que o tipo sentinela real (por exemplo, o tipo retornado por r.end()) é do mesmo tipo que o próprio iterador ou não?