A referência nula é possível?

Este pedaço de código é válido (e comportamento definido)?

int &nullReference = *(int*)0;

Ambos g ++ e clang ++ compilação-lo sem qualquer aviso, mesmo quando se usa -Wall, -Wextra, -std=c++98, -pedantic, -Weffc++...

Claro que a referência não é realmente nula, uma vez que não pode ser acessada (significaria desreferenciar um ponteiro nulo), mas poderíamos verificar se é nulo ou não verificando seu endereço:

if( & nullReference == 0 ) // null reference

As referências não são indicadores.

8.3.2 / 1:

Uma referência deve obrigatoriamente ser inicializada para se referir a um objeto ou função válida. [Nota: em particular, uma referência nula não pode existir em um programa bem definido, porque a única maneira de criar tal referência seria vinculá-la ao “objeto” obtido pela desreferenciação de um ponteiro nulo, o que causa um comportamento indefinido. Conforme descrito em 9.6, uma referência não pode ser vinculada diretamente a um campo de bits. ]

1.9 / 4:

Certas outras operações são descritas nesta Norma Internacional como indefinidas (por exemplo, o efeito de desreferenciar o ponteiro nulo)

Como Johannes diz em uma resposta excluída, há algumas dúvidas se "desreferenciar um ponteiro nulo" deve ser categoricamente declarado como comportamento indefinido. Mas este não é um dos casos que levantam dúvidas, uma vez que um ponteiro nulo certamente não aponta para um "objeto ou função válida", e não há desejo dentro do comitê de padrões de introduzir referências nulas.

A resposta depende do seu ponto de vista:

Se você julgar pelo padrão C ++, não poderá obter uma referência nula porque obtém o comportamento indefinido primeiro. Depois dessa primeira incidência de comportamento indefinido, o padrão permite que tudo aconteça. Então, se você escreve *(int*)0, você já tem um comportamento indefinido, do ponto de vista do padrão da linguagem, desreferenciando um ponteiro nulo. O resto do programa é irrelevante, uma vez que esta expressão seja executada, você está fora do jogo.

No entanto, na prática, as referências nulas podem ser facilmente criadas a partir de ponteiros nulos e você não notará até que realmente tente acessar o valor por trás da referência nula. Seu exemplo pode ser um pouco simples demais, pois qualquer bom compilador de otimização verá o comportamento indefinido e simplesmente otimizará qualquer coisa que dependa dele (a referência nula nem será criada, ela será otimizada).

No entanto, essa otimização depende do compilador para provar o comportamento indefinido, o que pode não ser possível fazer. Considere esta função simples dentro de um arquivo converter.cpp:

int& toReference(int* pointer) {
    return *pointer;
}

Quando o compilador vê essa função, ele não sabe se o ponteiro é um ponteiro nulo ou não. Portanto, ele apenas gera código que transforma qualquer ponteiro na referência correspondente. (Btw: Este é um noop, pois ponteiros e referências são exatamente a mesma besta no assembler.) Agora, se você tiver outro arquivo user.cppcom o código

#include "converter.h"

void foo() {
    int& nullRef = toReference(nullptr);
    cout << nullRef;    //crash happens here
}

o compilador não sabe que toReference()cancelará a referência ao ponteiro passado e presumirá que ele retornará uma referência válida, que na prática será uma referência nula. A chamada é bem-sucedida, mas quando você tenta usar a referência, o programa falha. Esperançosamente. O padrão permite que qualquer coisa aconteça, incluindo o aparecimento de elefantes rosa.

Você pode perguntar por que isso é relevante, afinal, o comportamento indefinido já foi acionado internamente toReference(). A resposta é depuração: referências nulas podem se propagar e proliferar da mesma forma que os ponteiros nulos fazem. Se você não está ciente de que podem existir referências nulas e aprende a evitar criá-las, você pode passar algum tempo tentando descobrir por que sua função de membro parece travar quando está apenas tentando ler um intmembro antigo comum (resposta: a instância na chamada do membro havia uma referência nula, então thisé um ponteiro nulo, e seu membro é calculado para estar localizado como endereço 8).

Então, que tal verificar referências nulas? Você deu a linha

if( & nullReference == 0 ) // null reference

em sua pergunta. Bem, isso não funcionará: de acordo com o padrão, você tem um comportamento indefinido se desreferenciar um ponteiro nulo e não pode criar uma referência nula sem desreferenciar um ponteiro nulo, portanto, as referências nulas existem apenas dentro do domínio do comportamento indefinido. Visto que seu compilador pode assumir que você não está disparando um comportamento indefinido, ele pode assumir que não existe uma referência nula (embora ele emita prontamente um código que gera referências nulas!). Como tal, ele vê a if()condição, conclui que não pode ser verdade e apenas joga fora a if()afirmação inteira . Com a introdução de otimizações de tempo de link, tornou-se totalmente impossível verificar referências nulas de uma maneira robusta.

TL; DR:

Referências nulas são um tanto quanto uma existência horrível:

A existência deles parece impossível (= pelo padrão),
mas eles existem (= pelo código de máquina gerado),
mas você não pode vê-los se eles existirem (= suas tentativas serão otimizadas),
mas eles podem matá-lo sem saber de qualquer maneira (= seu programa trava em pontos estranhos, ou pior).
Sua única esperança é que eles não existam (= escreva seu programa para não criá-los).

Espero que isso não venha a assombrá-lo!

Se sua intenção era encontrar uma maneira de representar null em uma enumeração de objetos singleton, então é uma má ideia (des) referenciar null (é C ++ 11, nullptr).

Por que não declarar o objeto singleton estático que representa NULL dentro da classe como segue e adicionar um operador cast-to-pointer que retorna nullptr?

Editar: vários tipos de erros corrigidos e adição de instrução if em main () para testar o funcionamento do operador cast-to-pointer (que esqueci de ... meu erro) - 10 de março de 2015 -

// Error.h
class Error {
public:
  static Error& NOT_FOUND;
  static Error& UNKNOWN;
  static Error& NONE; // singleton object that represents null

public:
  static vector<shared_ptr<Error>> _instances;
  static Error& NewInstance(const string& name, bool isNull = false);

private:
  bool _isNull;
  Error(const string& name, bool isNull = false) : _name(name), _isNull(isNull) {};
  Error() {};
  Error(const Error& src) {};
  Error& operator=(const Error& src) {};

public:
  operator Error*() { return _isNull ? nullptr : this; }
};

// Error.cpp
vector<shared_ptr<Error>> Error::_instances;
Error& Error::NewInstance(const string& name, bool isNull = false)
{
  shared_ptr<Error> pNewInst(new Error(name, isNull)).
  Error::_instances.push_back(pNewInst);
  return *pNewInst.get();
}

Error& Error::NOT_FOUND = Error::NewInstance("NOT_FOUND");
//Error& Error::NOT_FOUND = Error::NewInstance("UNKNOWN"); Edit: fixed
//Error& Error::NOT_FOUND = Error::NewInstance("NONE", true); Edit: fixed
Error& Error::UNKNOWN = Error::NewInstance("UNKNOWN");
Error& Error::NONE = Error::NewInstance("NONE");

// Main.cpp
#include "Error.h"

Error& getError() {
  return Error::UNKNOWN;
}

// Edit: To see the overload of "Error*()" in Error.h actually working
Error& getErrorNone() {
  return Error::NONE;
}

int main(void) {
  if(getError() != Error::NONE) {
    return EXIT_FAILURE;
  }

  // Edit: To see the overload of "Error*()" in Error.h actually working
  if(getErrorNone() != nullptr) {
    return EXIT_FAILURE;
  }
}

o clang ++ 3.5 ainda avisa sobre isso:

/tmp/a.C:3:7: warning: reference cannot be bound to dereferenced null pointer in well-defined C++ code; comparison may be assumed to
      always evaluate to false [-Wtautological-undefined-compare]
if( & nullReference == 0 ) // null reference
      ^~~~~~~~~~~~~    ~
1 warning generated.