ponteiros não opcionais vs. referências não const em C ++

Em Outros recursos do C ++, argumentos de referência do Guia de estilos do Google C ++ , li que referências não-const não devem ser usadas.

Todos os parâmetros passados ​​por referência devem ser rotulados como const.

É claro que observar chamadas de função que usam referências como argumentos é absolutamente confuso para programadores em C, mas C e C ++ são linguagens diferentes agora. Se um parâmetro de saída for necessário , o uso de um ponteiro para um parâmetro de saída necessário pode fazer com que todo o corpo da função seja ignorado, o que dificulta a implementação de uma função (aumenta formalmente a complexidade ciclomática e a profundidade de uma função).

Gostaria de tornar o código C ++ o mais fácil de entender / manter possível, por isso geralmente estou interessado em ler os guias de estilo de codificação. Mas, para adaptar as melhores práticas em uma equipe, acho que entender a lógica por trás dos elementos do guia de estilo é um fator importante.

As referências não constantes são realmente tão ruins? A proibição é apenas específica do Google ou é uma regra comumente aceita? O que justifica o esforço extra para implementar parâmetros de saída como ponteiros?

A lógica por trás do guia de estilo do Google é simplesmente deixar claro no site de chamada de uma função se um parâmetro é um parâmetro de entrada ou um parâmetro de saída. (Veja aqui para discussão adicional.) Outros idiomas definem parâmetros explícitos por design; C #, por exemplo, tem uma outpalavra - chave que deve ser usada no site de chamada . Como o C ++ não o torna explícito, o Google optou por usar const ref. versus ponteiro para deixar claro.

Isso é apenas uma regra do Google? Não, mas duvido que seja muito difundido. Acho que não vi isso fora do guia de estilo e dos grupos do Google que aderem explicitamente a partes do guia de estilo do Google. (Por exemplo, gostei da ideia quando li o guia de estilo do Google anos atrás e o usei para alguns dos meus códigos.)

Em particular, as Diretrizes Principais do C ++ recém-anunciadas preferem valores de retorno aos parâmetros de saída para (quase) tudo e usam refs não-constantes para o resto. O uso de ponteiros e referências pelo Google pode tornar os parâmetros de saída mais claros, mas os valores de retorno ainda são mais claros. Agora que o C ++ 11 possui movimentos padronizados (referências de rvalue,, &&para fazer retornos de muitos tipos baratos) e tuplas (permitindo uma maneira fácil de retornar vários valores), muitos dos casos de uso de parâmetros out já não se aplicam.

As Diretrizes Principais do C ++ têm alguns grandes nomes (Bjarne Stroustrup, Herb Sutter), são suportadas pela Microsoft e adotam os recursos mais recentes do C ++ (ao contrário do guia de estilos do Google), então espero que suas recomendações sejam mais populares que as do Google.

Existem 2 opções para lidar com um ponteiro inválido passado, primeira verificação e retorno antecipado ou que seja um comportamento indefinido (se você se importa mais com velocidade do que com robustez).

A verificação é tão simples quanto:

void foo(void* buffer){
    if(buffer == nullptr)
        return;

    //actually foo

    // note no increase in indentation required

}

Esse tipo de verificação geralmente é aceito como uma verificação de parâmetro. Se você vir o código, é bastante claro que espera que um ponteiro não nulo seja passado e retorne mais cedo, caso contrário. Isso permite que você não se preocupe tanto com ponteiros inválidos.

Tudo se resume à sua observação If an output parameter is required.

O único local em que uma assinatura de função é necessária para ter um parâmetro de saída é quando ela é especificada por uma API externa e, nesse caso, você apenas envolve a API externa em algo que garante que sempre haja um pontapé válido.

Internamente, você evita os parâmetros de saída estendendo o tipo de retorno para ser um composto de todas as "saídas"