Entendo a sintaxe e a semântica geral de ponteiros versus referências, mas como devo decidir quando é mais ou menos apropriado usar referências ou ponteiros em uma API?

Naturalmente, algumas situações precisam de uma ou de outra ( operator++precisa de um argumento de referência), mas, em geral, estou descobrindo que prefiro usar ponteiros (e const), pois a sintaxe é clara: as variáveis ​​estão sendo passadas destrutivamente.

Por exemplo, no seguinte código:

void add_one(int& n) { n += 1; }
void add_one(int* const n) { *n += 1; }
int main() {
  int a = 0;
  add_one(a); // Not clear that a may be modified
  add_one(&a); // 'a' is clearly being passed destructively
}

Com o ponteiro, é sempre (mais) óbvio o que está acontecendo; portanto, para APIs e afins, onde a clareza é uma grande preocupação, os ponteiros não são mais apropriados que as referências? Isso significa que as referências devem ser usadas apenas quando necessário (por exemplo operator++)? Há alguma preocupação de desempenho com um ou outro?

EDITAR (ATUALIZADO):

Além de permitir valores NULL e lidar com matrizes brutas, parece que a escolha se resume à preferência pessoal. Aceitei a resposta abaixo que faz referência ao Guia de estilo C ++ do Google , pois apresenta a visão de que "As referências podem ser confusas, pois possuem sintaxe de valor, mas semântica de ponteiro".

Devido ao trabalho adicional necessário para limpar argumentos de ponteiro que não devem ser NULL (por exemplo add_one(0), chamará a versão do ponteiro e interromperá durante o tempo de execução), faz sentido do ponto de vista da manutenção usar referências onde um objeto DEVE estar presente, embora seja uma vergonha perder a clareza sintática.

Use referência sempre que puder, indicadores sempre que precisar.

Evite ponteiros até não conseguir.

A razão é que os indicadores tornam as coisas mais difíceis de seguir / ler, menos seguras e muito mais perigosas do que qualquer outra construção.

Portanto, a regra geral é usar ponteiros apenas se não houver outra opção.

Por exemplo, retornar um ponteiro para um objeto é uma opção válida quando a função pode retornar nullptr em alguns casos e supõe-se que sim. Dito isto, uma opção melhor seria usar algo semelhante boost::optional.

Outro exemplo é usar ponteiros para a memória não processada para manipulações de memória específicas. Isso deve estar oculto e localizado em partes muito estreitas do código, para ajudar a limitar as partes perigosas de toda a base de código.

No seu exemplo, não faz sentido usar um ponteiro como argumento porque:

1. se você fornecer nullptrcomo argumento, estará em terreno de comportamento indefinido;
2. a versão do atributo de referência não permite (sem truques fáceis de identificar) o problema com 1.
3. a versão do atributo de referência é mais simples de entender para o usuário: você precisa fornecer um objeto válido, não algo que possa ser nulo.

Se o comportamento da função precisar trabalhar com ou sem um determinado objeto, o uso de um ponteiro como atributo sugere que você pode passar nullptrcomo argumento e isso é bom para a função. Esse é o tipo de contrato entre o usuário e a implementação.

As performances são exatamente as mesmas, pois as referências são implementadas internamente como ponteiros. Portanto, você não precisa se preocupar com isso.

Não existe uma convenção geralmente aceita sobre quando usar referências e ponteiros. Em alguns casos, você deve retornar ou aceitar referências (construtor de cópias, por exemplo), mas fora isso, você é livre para fazer o que quiser. Uma convenção bastante comum que encontrei é usar referências quando o parâmetro deve fazer referência a um objeto existente e ponteiros quando um valor NULL estiver ok.

Algumas convenções de codificação (como a do Google ) prescrevem que sempre se deve usar ponteiros ou referências const, porque as referências têm um pouco de sintaxe pouco clara: elas têm comportamento de referência, mas valorizam a sintaxe.

Do C ++ FAQ Lite -

Use referências quando puder e ponteiros quando precisar.

As referências geralmente são preferidas aos ponteiros sempre que você não precisar "recolocar". Isso geralmente significa que as referências são mais úteis na interface pública de uma classe. As referências geralmente aparecem na capa de um objeto e ponteiros no interior.

A exceção acima é onde o parâmetro ou valor de retorno de uma função precisa de uma referência "sentinela" - uma referência que não se refere a um objeto. Isso geralmente é melhor retornando / pegando um ponteiro e atribuindo ao ponteiro NULL esse significado especial (as referências devem sempre usar alias de objetos, não um ponteiro NULL desreferenciado).

Nota: Os programadores da linha C antiga às vezes não gostam de referências, pois fornecem semântica de referência que não está explícita no código do chamador. Após alguma experiência em C ++, no entanto, percebe-se rapidamente que essa é uma forma de ocultar informações, que é um ativo e não um passivo. Por exemplo, os programadores devem escrever código no idioma do problema e não no idioma da máquina.

Minha regra de ouro é:

• Use ponteiros para parâmetros de saída ou entrada / saída. Portanto, pode-se ver que o valor será alterado. (Você deve usar &)
• Use ponteiros se o parâmetro NULL for um valor aceitável. (Verifique constse é um parâmetro de entrada)
• Use referências para o parâmetro recebido se não puder ser NULL e não for um tipo primitivo ( const T&).
• Use ponteiros ou ponteiros inteligentes ao retornar um objeto recém-criado.
• Use ponteiros ou ponteiros inteligentes como membros de estrutura ou classe em vez de referências.
• Use referências para alias (por exemplo int &current = someArray[i])

Independentemente de qual você usar, não se esqueça de documentar suas funções e o significado de seus parâmetros se eles não forem óbvios.

Isenção de responsabilidade: além do fato de que as referências não podem ser NULL nem "rebote" (o que significa que elas não podem alterar o objeto do qual são o apelido), tudo se resume a uma questão de gosto, por isso não vou dizer "isto é melhor".

Dito isso, eu discordo de sua última declaração no post, pois não acho que o código perca clareza com referências. No seu exemplo,

add_one(&a);

pode ser mais claro que

add_one(a);

pois você sabe que provavelmente o valor de a mudará. Por outro lado, porém, a assinatura da função

void add_one(int* const n);

também não está claro: n será um único número inteiro ou uma matriz? Às vezes, você só tem acesso a cabeçalhos (mal documentados) e assinaturas como

foo(int* const a, int b);

não são fáceis de interpretar à primeira vista.

Portanto, as referências são tão boas quanto indicadores quando não é necessária (re) alocação ou religação (no sentido explicado anteriormente). Além disso, se um desenvolvedor usa apenas ponteiros para matrizes, as assinaturas de funções são um pouco menos ambíguas. Sem mencionar o fato de que a sintaxe dos operadores é muito mais legível com as referências.

Como outros já respondidos: Sempre use referências, a menos que a variável seja NULL/ nullptrseja realmente um estado válido.

O ponto de vista de John Carmack sobre o assunto é semelhante:

Ponteiros NULL são o maior problema em C / C ++, pelo menos em nosso código. O uso duplo de um valor único como sinalizador e endereço causa um número incrível de problemas fatais. Referências em C ++ devem ser favorecidas sobre ponteiros sempre que possível; embora uma referência seja "realmente" apenas um ponteiro, ela tem o contrato implícito de não ser NULL. Execute verificações NULL quando os ponteiros forem transformados em referências; depois, você poderá ignorar o problema.

http://www.altdevblogaday.com/2011/12/24/static-code-analysis/

Editar 2012-03-13

O usuário Bret Kuhns observa corretamente:

O padrão C ++ 11 foi finalizado. Acho que está na hora de mencionar que a maioria dos códigos deve se sair perfeitamente bem com uma combinação de referências, shared_ptr e unique_ptr.

É verdade, mas a questão ainda permanece, mesmo ao substituir ponteiros brutos por ponteiros inteligentes.

Por exemplo, ambos std::unique_ptre std::shared_ptrpodem ser construídos como ponteiros "vazios" por meio de seu construtor padrão:

• http://en.cppreference.com/w/cpp/memory/unique_ptr/unique_ptr
• http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr

... significando que usá-los sem verificar se não estão vazios corre o risco de um acidente, que é exatamente o que trata a discussão de J. Carmack.

E então, temos o divertido problema de "como passamos um ponteiro inteligente como parâmetro de função?"

A resposta de Jon para a pergunta C ++ - passando referências para boost :: shared_ptr , e os comentários a seguir mostram que, mesmo assim, passar um ponteiro inteligente por cópia ou por referência não é tão claro quanto se gostaria (eu sou a favor de " por referência "por padrão, mas posso estar errado).

Não é uma questão de gosto. Aqui estão algumas regras definitivas.

Se você quiser se referir a uma variável declarada estaticamente dentro do escopo em que foi declarada, use uma referência C ++ e ela será perfeitamente segura. O mesmo se aplica a um ponteiro inteligente declarado estaticamente. A passagem de parâmetros por referência é um exemplo desse uso.

Se você quiser se referir a algo de um escopo mais amplo que o escopo em que foi declarado, use um ponteiro inteligente contado como referência para que seja perfeitamente seguro.

Você pode se referir a um elemento de uma coleção com uma referência para conveniência sintática, mas não é seguro; o elemento pode ser excluído a qualquer momento.

Para manter com segurança uma referência a um elemento de uma coleção, você deve usar um ponteiro inteligente contado como referência.

Qualquer diferença de desempenho seria tão pequena que não justificaria usar uma abordagem menos clara.

Primeiro, um caso que não foi mencionado em que as referências geralmente são superiores são as constreferências. Para tipos não simples, passar umconst reference evita a criação de um temporário e não causa a confusão com a qual você se preocupa (porque o valor não é modificado). Aqui, forçar uma pessoa a passar um ponteiro causa a mesma confusão com a qual você está preocupado, pois ver o endereço recebido e passado para uma função pode fazer você pensar que o valor foi alterado.

De qualquer forma, basicamente concordo com você. Não gosto de funções que façam referências para modificar seu valor quando não é muito óbvio que é isso que a função está fazendo. Eu também prefiro usar ponteiros nesse caso.

Quando você precisa retornar um valor em um tipo complexo, eu tendem a preferir referências. Por exemplo:

bool GetFooArray(array &foo); // my preference
bool GetFooArray(array *foo); // alternative

Aqui, o nome da função deixa claro que você está recebendo informações de volta em uma matriz. Portanto, não há confusão.

As principais vantagens das referências são que elas sempre contêm um valor válido, são mais limpas do que ponteiros e suportam polimorfismos sem precisar de nenhuma sintaxe extra. Se nenhuma dessas vantagens se aplicar, não há motivo para preferir uma referência a um ponteiro.

Copiado do wiki -

Uma conseqüência disso é que, em muitas implementações, operando em uma variável com vida útil automática ou estática por meio de uma referência, embora sintaticamente semelhante ao acesso direto a ela, pode envolver operações de desreferência ocultas que são caras. As referências são um recurso sintaticamente controverso do C ++ porque obscurecem o nível de indireção de um identificador; ou seja, diferentemente do código C, em que os ponteiros geralmente se destacam sintaticamente, em um grande bloco de código C ++ pode não ser imediatamente óbvio se o objeto acessado for definido como uma variável local ou global ou se é uma referência (ponteiro implícito) a em outro local, principalmente se o código combinar referências e ponteiros. Esse aspecto pode dificultar a leitura e a depuração do código C ++ mal escrito (consulte Alias).

Concordo 100% com isso, e é por isso que acredito que você só deve usar uma referência quando tiver um bom motivo para fazê-lo.

Pontos a serem lembrados:

1. Ponteiros podem ser NULL, referências não podem ser NULL.

2. As referências são mais fáceis de usar, constpodem ser usadas para uma referência quando não queremos alterar valor e precisamos apenas de uma referência em uma função.

3. Ponteiro usado com um *tempo referências usadas com um &.

4. Use ponteiros quando a operação aritmética do ponteiro for necessária.

5. Você pode ter ponteiros para um tipo de nulo, int a=5; void *p = &a;mas não pode ter uma referência a um tipo de nulo.

Ponteiro versus referência

void fun(int *a)
{
    cout<<a<<'\n'; // address of a = 0x7fff79f83eac
    cout<<*a<<'\n'; // value at a = 5
    cout<<a+1<<'\n'; // address of a increment by 4 bytes(int) = 0x7fff79f83eb0
    cout<<*(a+1)<<'\n'; // value here is by default = 0
}
void fun(int &a)
{
    cout<<a<<'\n'; // reference of original a passed a = 5
}
int a=5;
fun(&a);
fun(a);

Veredicto quando usar o que

Ponteiro : Para matriz, lista de links, implementações em árvore e aritmética de ponteiros.

Referência : em parâmetros de função e tipos de retorno.

Há um problema com a regra " usar referências sempre que possível " e surge se você deseja manter a referência para uso posterior. Para ilustrar isso com um exemplo, imagine que você tenha as seguintes classes.

class SimCard
{
    public:
        explicit SimCard(int id):
            m_id(id)
        {
        }

        int getId() const
        {
            return m_id;
        }

    private:
        int m_id;
};

class RefPhone
{
    public:
        explicit RefPhone(const SimCard & card):
            m_card(card)
        {
        }

        int getSimId()
        {
            return m_card.getId();
        }

    private:
        const SimCard & m_card;
};

A princípio, pode parecer uma boa idéia ter um parâmetro no RefPhone(const SimCard & card)construtor passado por uma referência, porque impede a passagem de ponteiros errados / nulos para o construtor. De alguma forma, incentiva a alocação de variáveis ​​na pilha e aproveita os benefícios do RAII.

PtrPhone nullPhone(0);  //this will not happen that easily
SimCard * cardPtr = new SimCard(666);  //evil pointer
delete cardPtr;  //muahaha
PtrPhone uninitPhone(cardPtr);  //this will not happen that easily

Mas então os temporários vêm para destruir seu mundo feliz.

RefPhone tempPhone(SimCard(666));   //evil temporary
//function referring to destroyed object
tempPhone.getSimId();    //this can happen

Portanto, se você cegar cegamente às referências, reduz a possibilidade de passar ponteiros inválidos para a possibilidade de armazenar referências a objetos destruídos, que basicamente têm o mesmo efeito.

editar: observe que eu me apeguei à regra "Use referências sempre que puder, indicadores sempre que precisar. Evite indicadores até não conseguir". da resposta mais votada e aceita (outras respostas também sugerem isso). Embora deva ser óbvio, o exemplo não é mostrar que as referências são ruins. No entanto, eles podem ser mal utilizados, como ponteiros e podem trazer suas próprias ameaças ao código.

Existem as seguintes diferenças entre ponteiros e referências.

1. Quando se trata de passar variáveis, passar por referência parece passar por valor, mas possui semântica de ponteiro (age como ponteiro).
2. A referência não pode ser inicializada diretamente como 0 (nulo).
3. A referência (objeto de referência, não referenciado) não pode ser modificada (equivalente ao ponteiro "* const").
4. A referência const pode aceitar parâmetro temporário.
5. As referências const locais prolongam a vida útil dos objetos temporários

Levando isso em consideração, minhas regras atuais são as seguintes.

• Use referências para parâmetros que serão usados ​​localmente dentro de um escopo de função.
• Use ponteiros quando 0 (nulo) for o valor aceitável do parâmetro ou você precisar armazenar o parâmetro para uso posterior. Se 0 (nulo) for aceitável, estou adicionando o sufixo "_n" ao parâmetro, use o ponteiro protegido (como QPointer no Qt) ou apenas documente. Você também pode usar ponteiros inteligentes. É necessário ter ainda mais cuidado com os ponteiros compartilhados do que com os ponteiros normais (caso contrário, você poderá acabar com vazamentos de memória de design e bagunça de responsabilidade).

A seguir estão algumas diretrizes.

Uma função usa dados passados ​​sem modificá-los:

1. Se o objeto de dados for pequeno, como um tipo de dados interno ou uma estrutura pequena, transmita-o por valor.

2. Se o objeto de dados for uma matriz, use um ponteiro, porque essa é sua única opção. Faça do ponteiro um ponteiro para const.

3. Se o objeto de dados for uma estrutura de bom tamanho, use um ponteiro const ou uma referência const para aumentar a eficiência do programa. Você economiza tempo e espaço necessários para copiar uma estrutura ou um design de classe. Faça o ponteiro ou a referência const.

4. Se o objeto de dados é um objeto de classe, use uma referência const. A semântica do design de classe geralmente exige o uso de uma referência, que é o principal motivo pelo qual o C ++ adicionou esse recurso.

Uma função modifica os dados na função de chamada:

1.Se o objeto de dados for um tipo de dados interno, use um ponteiro. Se você localizar código como fixit (& x), em que x é um int, é bastante claro que essa função pretende modificar x.

2.Se o objeto de dados for uma matriz, use sua única opção: um ponteiro.

3.Se o objeto de dados for uma estrutura, use uma referência ou um ponteiro.

4.Se o objeto de dados for um objeto de classe, use uma referência.

Obviamente, essas são apenas diretrizes e pode haver razões para fazer escolhas diferentes. Por exemplo, cin usa referências para tipos básicos, para que você possa usar cin >> n em vez de cin >> & n.

As referências são mais limpas e fáceis de usar, além de ocultar melhor as informações. As referências não podem ser reatribuídas, no entanto. Se você precisar apontar primeiro para um objeto e depois para outro, use um ponteiro. As referências não podem ser nulas; portanto, se houver alguma chance de o objeto em questão ser nulo, você não deve usar uma referência. Você deve usar um ponteiro. Se você deseja lidar com a manipulação de objetos por conta própria, ou seja, se você deseja alocar espaço de memória para um objeto no Heap e não na Stack, use o Ponteiro

int *pInt = new int; // allocates *pInt on the Heap

Seu exemplo escrito corretamente deve parecer

void add_one(int& n) { n += 1; }
void add_one(int* const n)
{
  if (n)
    *n += 1;
}

É por isso que as referências são preferíveis, se possível ...

Apenas colocando minha moeda. Acabei de realizar um teste. Um sorrateiro nisso. Eu apenas deixei o g ++ criar os arquivos de montagem do mesmo miniprograma usando ponteiros em comparação ao uso de referências. Ao olhar para a saída, eles são exatamente os mesmos. Diferente da simbologia. Portanto, analisando o desempenho (em um exemplo simples), não há problema.

Agora, no tópico ponteiros vs referências. IMHO Eu acho que a clareza está acima de tudo. Assim que leio o comportamento implícito, meus dedos começam a se enrolar. Concordo que é um bom comportamento implícito que uma referência não possa ser NULL.

Desreferenciar um ponteiro NULL não é o problema. ele travará seu aplicativo e será fácil depurar. Um problema maior são os ponteiros não inicializados que contêm valores inválidos. Isso provavelmente resultará em corrupção de memória, causando um comportamento indefinido sem uma origem clara.

É aqui que acho que as referências são muito mais seguras do que indicadores. E eu concordo com uma declaração anterior, de que a interface (que deve ser claramente documentada, veja o projeto por contrato, Bertrand Meyer) define o resultado dos parâmetros para uma função. Agora, levando tudo isso em consideração, minhas preferências vão para o uso de referências sempre que possível.

Para ponteiros, você precisa apontar para alguma coisa, para que os ponteiros custem espaço na memória.

Por exemplo, uma função que usa um ponteiro inteiro não aceita a variável inteira. Portanto, você precisará criar um ponteiro para que o primeiro passe para a função.

Quanto a uma referência, não custará memória. Você tem uma variável inteira e pode transmiti-la como uma variável de referência. É isso aí. Você não precisa criar uma variável de referência especialmente para ela.