Инициализировать или не инициализировать , it's the question

Цитата Flex Ferrum @ 20.11.15, 08:29

Состоятелен. "Мусор" и "дефолтное значение" - это термины в инвариантах типа. Для std::string "пустое значение" является допустимым состоянием после инициализации. Для int'а - "мусор" тоже является допустимым состоянием. То есть любая операция над int'ом с "мусором" успешно выполнится. А вот с точки зрения конкретного куска кода, который использует int или string, как "мусор", так и "пустая строка" могут быть недопустимыми значениями. Но это с точки зрения использующего их кода. Понимаешь разницу? То есть default initialization приводит объект (любого типа) в согласованное состояние с точки зрения типа, но не гарантирует допустимость этого состояния с точки зрения пользователя.

+1 Именно так. Инициализировать надо тем, чем нужно, и тогда, когда нужно. А инициализация "чем-попало" (пусть нулем), на всякий случай - признак паранойи. Более того, неправильная инициализация "на всякий случай", привенест дополнительную уверенность в том, что "авось прокатит, даже если ошибусь". От лукавого это!

Цитата Pacific @ 20.11.15, 06:36

Если i передается как неконстантный указатель, то после этого вызова она будет считаться инициализированной. Реализация extern_function на совести того, кто ее писал. Вообще, понадобится синтаксис, объясняющий компилятору, что вот этот формальный параметр функции - неинициализированный, и его нельзя сразу использовать.

Так решение-то какое? Разрешать или запрещать такое?

shm
Запретить "int x;" без инициализации. "int x = void;" - тоже сомнительно. Переменную можно объявить в том блоке, где она впервые используется, и сразу же инициализировать разумным начальным значением.

Цитата JoeUser @ 20.11.15, 10:58

+1 Именно так. Инициализировать надо тем, чем нужно, и тогда, когда нужно. А инициализация "чем-попало" (пусть нулем), на всякий случай - признак паранойи. Более того, неправильная инициализация "на всякий случай", привенест дополнительную уверенность в том, что "авось прокатит, даже если ошибусь". От лукавого это!

То есть когда std::string инициализируется "чем попало" (пустой строкой) - это нормально, а int уже не нормально.

Сообщение отредактировано: applegame - 20.11.15, 11:52

Цитата applegame @ 20.11.15, 09:59

Это другая крайность. Безопасность в ущерб читабельности и удобству.

А вот я не уверен, что "в ущерб". На самом деле, тут так же, как со всякими разными cast'ами.

Добавлено 20.11.15, 12:14

Цитата applegame @ 20.11.15, 11:51

То есть когда std::string инициализируется "чем попало" (пустой строкой) - это нормально, а int уже не нормально.

Ещё раз. И string и int (с точки зрения клиента) инициализируются "чем попало" в случае default-инициализации.

Добавлено 20.11.15, 12:16

Цитата D_KEY @ 20.11.15, 10:19

Но ведь она уже сделана для некоторых типов. А для некоторых у нас мусор.

Для "некоторых типов" её делает сам разработчик, а не компилятор.

Цитата Flex Ferrum @ 20.11.15, 12:12

Ещё раз. И string и int (с точки зрения клиента) инициализируются "чем попало" в случае default-инициализации.

В таком случае std::string нарушает принцип нулевой стоимости. Как люди последовательные, мы должны потребовать, чтобы конструктор по умолчанию для std::string заполнял всё мусором

Цитата Flex Ferrum @ 20.11.15, 12:12

Ещё раз. И string и int (с точки зрения клиента) инициализируются "чем попало" в случае default-инициализации.

Еще раз, с точки зрения клиента, string инициализируется конкретным значением, а int действительно, чем попало. Ты агрументируешь в стиле: с точки зрения банальной эрудиции, и атеизм и христианство являются религиями.

Сообщение отредактировано: applegame - 20.11.15, 12:20

Цитата applegame @ 20.11.15, 12:20

Цитата Flex Ferrum @ 20.11.15, 12:12

Ещё раз. И string и int (с точки зрения клиента) инициализируются "чем попало" в случае default-инициализации.

Еще раз, с точки зрения клиента, string инициализируется конкретным значением, а int, действительно чем попало. Ты агрументируешь в стиле: с точки зрения банальной эрудиции, и атеизм и христианство являются религиями.

Нет, аргументация там такая: таков контракт этого типа. Контракт int - мусор, контракт std::string - пустая строка.

Цитата OpenGL @ 20.11.15, 08:12

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

Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее.
И поэтому тесты с такими ошибками ничего не могут поделать. Если функция должна искать максимум в векторе, а на самом деле ищет минимум, и документация писалась по коду, тест будет пасситься хоть тресни.

Добавлено 20.11.15, 12:38

Цитата applegame @ 20.11.15, 09:22

Ага, ленивый человек увидев отсутствие инициализации бросится перечитывать доку mmap. Не смешите, в реальности, как сказал D_KEY, ленивый человек тупо посмотрит на "== 0" и проинициализирует переменную нулем же. После чего ситуация станет эквивалентной неверной дефолтной инициализации.

Ну если васрать, то static_cast<> вам в помощь.

Цитата applegame @ 20.11.15, 09:22

Undefined Behavior - зло. И таких мест в языке должно быть, как можно меньше.

Безусловно. Но тестеры на тёмной стороне, и просто обожают UB, не знал?

Добавлено 20.11.15, 12:43

Цитата D_KEY @ 20.11.15, 10:19

Но ведь она уже сделана для некоторых типов. А для некоторых у нас мусор. Надо или делать мусор для всех, или вызывать дефолтный конструктор для всех. Ну или есть еще вариант с принудительным явным вызовом(и =void).

Более того, я бы даже для std::complex<> не делал бы дефолтную инициализацию, т.к. это класс без состояний, т.е. тупо POD, просто методов в него напихали.

Цитата Qraizer @ 20.11.15, 12:35

Проблема не в "поймать", а в "заметить, что оно неправильное". Это алгоритмическая ошибка, а не ошибка реализации. Поэтому анализировать нужно не код, который перед глазами, и который достаточно просто видеть, а алгоритм, который либо описан в документации, и его ещё надо сопоставить с кодом, либо его ещё надо восстановить по коду, что ещё сложнее.

Это я понял. Непонятно, почему int a; без инициализации при её необходимости - ошибка реализации, а то же самое, но с дефолтовой неверной инициализацией - ошибка алгоритма. По мне так принципиальной разницы между этими двумя случаями нет. Точнее, есть - второе работает неправильно всегда, но эта разница говорит скорей в его пользу, чем против.

Добавлено 20.11.15, 13:00

Цитата Qraizer @ 20.11.15, 12:35

Более того, я бы даже для std::complex<> не делал бы дефолтную инициализацию, т.к. это класс без состояний, т.е. тупо POD, просто методов в него напихали.

А для std::pair<int, int>? Или каких-нибудь указателей?
Последние, кстати, nullptr-ом инициализировать по-умолчанию вполне логично по той же причине, по которой дефолтовый std::string - пустая строка.

Сообщение отредактировано: OpenGL - 20.11.15, 13:02

Цитата OpenGL @ 20.11.15, 12:56

Последние, кстати, nullptr-ом инициализировать по-умолчанию вполне логично по той же причине, по которой дефолтовый std::string - пустая строка.

Ни в коем случае. Потому что

Цитата Qraizer @ 20.11.15, 12:35

тестеры на тёмной стороне, и просто обожают UB, не знал?

Сообщение отредактировано: applegame - 20.11.15, 13:03

Кстати, по поводу предложения всегда писать либо инициализатор, либо = void: а что будет означать последнее для пользовательских типов?

Цитата MyNameIsIgor @ 20.11.15, 13:18

Кстати, по поводу предложения всегда писать либо инициализатор, либо = void: а что будет означать последнее для пользовательских типов?

default initialization.

Цитата applegame @ 20.11.15, 11:51

То есть когда std::string инициализируется "чем попало" (пустой строкой) - это нормально, а int уже не нормально.

Цитата MyNameIsIgor @ 20.11.15, 12:18

В таком случае std::string нарушает принцип нулевой стоимости. Как люди последовательные, мы должны потребовать, чтобы конструктор по умолчанию для std::string заполнял всё мусором

int имеет предопределенный размер, меньше нельзя, он и получает мусор данного размера. Строка имеет меньший размер - нулевой, и получает нулевой ... мусор! В обеих случаях все равнозначно. И это правильно. Повторюсь, хватит "бессмысленных страховочных" действий! Вы еще перепроверьте на всякий случай, а действительно ли процессор правильно сложил 5+5

Инициализировать надо там, где надо инициализировать. Проверять нужно то, что нужно проверять. Остальное от лукавого. И ваще, долой ваши жирные программы!

Цитата JoeUser @ 20.11.15, 13:34

Строка имеет меньший размер - нулевой

ЧЯДНТ?

Добавлено 20.11.15, 13:41

Цитата JoeUser @ 20.11.15, 13:34

И ваще, долой ваши жирные программы!

Вы полагаете, что ваши глючные лучше?