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

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

Так она есть. Для каждого типа default initialization строго описана.

Отсутствие инициализации - тоже инициализация. Офигительная казуистика.

Цитата MyNameIsIgor @ 20.11.15, 14:20

Мой вопрос то в другом: почему она разная? Для одних типов я получаю неопределённое поведение, а для вторых - нет.

В языке разные типы имеют разный "статус". Одни требуют вызов конструктора, другим он не нужен. Это же очевидно.

Цитата JoeUser @ 20.11.15, 14:25

Цитата MyNameIsIgor @ 20.11.15, 14:20

Мой вопрос то в другом: почему она разная? Для одних типов я получаю неопределённое поведение, а для вторых - нет.

В языке разные типы имеют разный "статус". Одни требуют вызов конструктора, другим он не нужен. Это же очевидно.

Для меня это не очевидно

Цитата MyNameIsIgor @ 20.11.15, 14:20

Хорошо, давайте zero initialization изменим.
Кстати, а почему пустая строка? Мне вот "abcd" нравится.

Так вот об том и речь: умолчательное поведение оно - как средняя температура по больнице.

Цитата MyNameIsIgor @ 20.11.15, 14:20

Не получится - например, при присваивании полезет удалять память по мусорному адресу.

inet_addr - это POD-тип. Кто, куда и для чего полезет? Или, вот, другой пример. CRITICAL_SECTION. Для этой POD-структуры никакого варианта адекватной инициализации по умолчанию просто не существует - нужно спец. функцию вызывать. Умолчательные значения для хэндлов в той же винде - очень сильно зависят от того, что это за хэндл. Где-то - 0, где-то - -1, где-то - nullptr. Весёлый такой зоопарк, да? И как с этим должно справляться zero-initialization по-умолчанию? В коде будет просто феерия, сложно отлавливаемая. Если, как написал Крайзер, обращение к неинциализированной переменной-хендлу ты ещё можешь отловить, то вот обращение к неправильно инициализированному хендлу - уже нет.

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

Цитата applegame @ 20.11.15, 14:24

Отсутствие инициализации - тоже инициализация. Офигительная казуистика.

Ну ты стандарт то открой.

Цитата Flex Ferrum @ 20.11.15, 14:27

inet_addr - это POD-тип. Кто, куда и для чего полезет?

std::vector полезет, если его конструуктор по умолчанию не проставит нулевой размер имеющихся данных.

Цитата JoeUser @ 20.11.15, 14:19

Кстати, смех смехом, а тогда бы любую переменную можно было бы инициализировать не подобием 0, NULL, nullptr - а однозначным NAN и ловить эксепшены при использовании неинициализированных переменных. Но это еще один слой жирка в и без того знатно пополневший Си.

В D все флоаты по умолчанию заполняются именно NaN - http://dlang.org/type
Поверь, жирка от инициализации по умолчанию, практически нет.

Цитата Flex Ferrum @ 20.11.15, 14:27

Или, вот, другой пример. CRITICAL_SECTION. Для этой POD-структуры никакого варианта адекватной инициализации по умолчанию просто не существует - нужно спец. функцию вызывать. Умолчательные значения для хэндлов в той же винде - очень сильно зависят от того, что это за хэндл. Где-то - 0, где-то - -1, где-то - nullptr. Весёлый такой зоопарк, да?

А сейчас он не весёлый, а вполне предсказумый что ли, с мусором то? Хуже не станет.

Цитата applegame @ 20.11.15, 14:24

Отсутствие инициализации - тоже инициализация. Офигительная казуистика.

Ничего странного. Инициализация - двухфазная операция (выделение памяти + приведение данных в изначальное рабочее состояние). Для встроенных типов вторая фаза не всегда нужна. Ее и не навязывают. Это нормально. Для библиотечних типов такое допустить нельзя, иначе объект будет в нестабильном состоянии. Встроенные типы на 100% функциональны сразу же после выделения памяти.

Цитата MyNameIsIgor @ 20.11.15, 14:29

А сейчас он не весёлый, а вполне предсказумый что ли, с мусором то? Хуже не станет.

Сейчас ты его статиканализаторами отловить можешь.

Цитата MyNameIsIgor @ 20.11.15, 14:28

std::vector полезет, если его конструуктор по умолчанию не проставит нулевой размер имеющихся данных.

Нет. Потому что у inet_addr нет конструктора и деструктора.

Скрытый текст

Цитата applegame @ 20.11.15, 14:29

Поверь, жирка от инициализации по умолчанию, практически нет.

Я еще до D толком не добрался, всему свое время. Пока не разберусь с D под LLVM, учить ниче не буду))

Цитата Flex Ferrum @ 20.11.15, 14:31

Нет. Потому что у inet_addr нет конструктора и деструктора.

А память то, память std::vector вернуть системе не желает?

Цитата MyNameIsIgor @ 20.11.15, 14:41

А память то, память std::vector вернуть системе не желает?

Так память то он вернёт. Тут ведь фишка в том, что именно будет в этой памяти.

Цитата Flex Ferrum @ 20.11.15, 14:43

Так память то он вернёт. Тут ведь фишка в том, что именно будет в этой памяти.

Как же он её вернёт, если указатель на данные будет мусорным? Это не говоря о том, что обращение к такой переменной - неопределённое поведение.
Напоминаю, я говорю о случае, когда std::vector не будет инициализировать свои поля в конструкторе по умолчанию.

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

Цитата Flex Ferrum @ 20.11.15, 14:31

Сейчас ты его статиканализаторами отловить можешь.

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

Цитата MyNameIsIgor @ 20.11.15, 14:46

Как же он её вернёт, если указатель на данные будет мусорным

Э... Что-то ты, видимо, не понимаешь. POD-структура занимает какой-то кусок памяти, равный по размеру её sizeof. Никого не интересует, что там в этом куске памяти. Вектор - в том числе. Его задача - выделить этот кусок и вернуть обратно при разрушении. А то, что там будет мусор (в полях POD-структуры) - так это не проблема vector'а.

Цитата Flex Ferrum @ 20.11.15, 15:01

Э... Что-то ты, видимо, не понимаешь.

Давайте поймём что.
Я говорю, что будь комитет последовательным, он требовал, чтобы std::vector<T> v; не тратило такты, как не тратит int x; Это может быть только тогда, когда конструктор по умолчанию не будет прописывать что-то в поля. В таком случае при операция с таким вектором мы получим неопределённое поведение, и как пример я указал присваивание ему другого вектора. И это не зависит от того, является ли T POD или не POD.
Чего я не понимаю?