Тип имя = имя;когда-нибудь полезный в C ++? - PullRequest
15 голосов
/ 01 августа 2011

В C ++ допускается следующий код:

int a = a;

или

Type name = name;

Оба приводят к инициализации неинициализированного объекта, что часто приводит к неопределенному поведению.

Является ли такой код когда-либо необходимым или разумным?Есть ли случаи, когда такой код полезен?

Ответы [ 5 ]

21 голосов
/ 01 августа 2011

Это напомнило мне старую ветку списка рассылки GCC , в которой Габриэль Дос Рейс привел следующий пример построения кольцевого списка из одного узла:

struct Node {
  Node* link;
  Node(Node& n) : link(&n) { }
};

int main()
{
  Node x = x;
}
17 голосов
/ 01 августа 2011

Вам разрешено использовать имя переменной в ее инициализаторе.Код

Type name = name;

, вероятно, бесполезен, но код

Type name = f(&name);

может быть.

Есть много мест, где синтаксис языка не запрещает бесполезныйстроит.: -)

3 голосов
/ 01 августа 2011

Иногда, если у вас есть сложные инициализаторы, вы можете обратиться к нему. Это используется в конструкторах, где вы передаете указатель или ссылки на this в списке инициализации.

1 голос
/ 01 августа 2011

Это действительно, но почти само собой разумеется, что

int a = a;

вреднее, чем нет.

Что касается других типов, я бы сказал, что можно выполнить полезную работу, перегружая конструктор копирования и используя конструкцию по умолчанию.

С другой стороны, я не могу думать ни о каких обстоятельствах, где такой код необходим, и, поскольку IMO-код настолько запутан этим синтаксисом, мое субъективное мнение состоит в том, что нет никаких веских причин, чтобы писать такие назначения. , Особенно если учесть все ошибки, которые можно предотвратить, запретив (или хотя бы предупредив) синтаксис.

0 голосов
/ 01 августа 2011

Такой код никогда не может быть полезным , что приводит к неопределенности.

Первый случай - неопределенное поведение (инициализация с неинициализированным self), а второй случай - также неопределенное поведение (конструктор копирования вызывается для неинициализированного объекта). Это никогда не должно практиковаться.

...