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

[Pacific]

Цитата shm @ 19.11.15, 18:08

Цитата Pacific @ 19.11.15, 15:05

добавить "int x = void;" когда инициализация действительно не нужна. Но при этом добавить ошибку компиляции, если потом попытаться использовать x без инициализации.

int i = void;
extern_function(&i);

?

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

[D_KEY]

Qraizer, спасибо за развёрнутый ответ. Можешь ещё пояснить разницу

int x;

и

string s;

в контексте

Цитата

Поэтому "int x;" и баста. Так короче. Ой, uninitialized var is used. "А, ну да, тут же надо = 0; ...или не 0 ?" Что, задумался? Правильно сделал, потому что 0 не всегда правильно.

?
Почему это логика применима к одним типам и не применима к другим?

Далее, нет ли тут противоречия:

Цитата

Человек по сути лентяй. Есть исключения в лице трудоголиков, но увы, большинство из нас лентяи, и мы не хотим делать что бы там ни было, если этого можем избежать. Поэтому "int x;" и баста. Так короче.

Цитата

если програмист C++ — напомню, изначально холивар был выделен из тематического вопроса про C, но сейчас рассматривается в контексте именно C++ — не пожелал сделать инициализацию прямо в определении, которое в C++ можно ткнуть в любое место блока, а значит определить переменную ровно в том месте, где её уже есть чем инициализировать, и не раньше, то наверное на это есть причины, потому что Плюсник в отличие от Сишника привык мыслить объектами, а не переменными, а у тех есть состояние, и первая мысль у Плюсника, закончившего вбивать имя переменной, должна быть "какое начальное состояние я должен ей дать?", и ежели вдруг его ещё нет, то рассмотреть возможность перенести определение ниже, но т.к. он такой возможности не нашёл, иначе бы не опускал инициализацию, значит отсутствие начального значения – факт, который уже рассмотрен, взвешен, и по нему принято решение

Сообщение отредактировано: D_KEY - 20.11.15, 07:36

[Flex Ferrum]

D_KEY, с int'ом и string'ом принципиальной разницы нет. И там, и там делается default initialization. Просто для сложных объектов существуют ещё и инварианты, которые должны выполняться после работы конструктора. Если когда-нибудь применял паттерн двойной инициализации, то, в общем, должен знать, что объявленный объект - далеко не всегда операбельный.

А Qraizer отлично всё расписал!

[D_KEY]

Цитата Flex Ferrum @ 20.11.15, 07:39

D_KEY, с int'ом и string'ом принципиальной разницы нет.

Значит аргумент не состоятелен. Ведь в случае int у нас будет мусор, а в случае string - дефолтное значение.

Цитата

Просто для сложных объектов существуют ещё и инварианты, которые должны выполняться после работы конструктора.

Верно.

Цитата

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

Должен.

Но, на мой взгляд, это никак не говорит в пользу мусора. Наоборот.

[OpenGL]

Цитата Qraizer @ 19.11.15, 12:05

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

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

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

[Flex Ferrum]

Цитата D_KEY @ 20.11.15, 07:54

Значит аргумент не состоятелен. Ведь в случае int у нас будет мусор, а в случае string - дефолтное значение.

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

[applegame]

Цитата Flex Ferrum @ 20.11.15, 07:39

А Qraizer отлично всё расписал!

Ой да ладно. Вся аргументация сводится к филосовским выводам на уровне: если документация неверна, то неверная дефолтная инициализация хуже, чем отсутствие инициализации вообще, потому что якобы выявление отсутствия инициализации тестами как-то может помочь с кривой документацией.
Ага, ленивый человек увидев отсутствие инициализации бросится перечитывать доку mmap. Не смешите, в реальности, как сказал D_KEY, ленивый человек тупо посмотрит на "== 0" и проинициализирует переменную нулем же. После чего ситуация станет эквивалентной неверной дефолтной инициализации. То есть мы получаем лишнюю итерацию при поиске ошибки.
Undefined Behavior - зло. И таких мест в языке должно быть, как можно меньше.

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

[Flex Ferrum]

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

то неверная дефолтная инициализация хуже, чем отсутствие инициализации вообще

Угу. Именно так. Проблему, кстати, может решить доведённое до логического финала предложение Майерса (ну, коль уж рушить backward compatibility). Сделать надо так: объявление _всегда_ должно содержать инициализирующую часть. И либо это будет " = void", либо конкретный инициализатор. Вот тогда всем будет хорошо. Ну, кроме тех, кто легаси-код поддерживает. А на любые объявления без инициализатора компилятор должен агриться и выдавать диагностику.

Сообщение отредактировано: Flex Ferrum - 20.11.15, 09:27

[D_KEY]

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

Для std::string "пустое значение" является допустимым состоянием после инициализации. Для int'а - "мусор" тоже является допустимым состоянием.

Цитата

То есть любая операция над int'ом с "мусором" успешно выполнится.

Но ведь это справедливо и для string, если мы создадим какую-то строку с мусорными символами.

Цитата

То есть default initialization приводит объект (любого типа) в согласованное состояние с точки зрения типа

Проблема в том, что это состояние неизвестно

[applegame]

Цитата D_KEY @ 20.11.15, 09:37

Проблема в том, что это состояние неизвестно

Ты ничего не понимаешь! Для встроенных типов неведомое состояние удовлетворяет инвариантам, самих встроенных типов!

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

[Flex Ferrum]

Цитата D_KEY @ 20.11.15, 09:37

Но ведь это справедливо и для string, если мы создадим какую-то строку с мусорными символами.

Справедливо. И тебе никто не мешает написать такой тип, состояние которого после дефолтной инициализации будет "неопределённым". Достаточно, например, воткнуть в него POD-структуру.

[applegame]

Цитата Flex Ferrum @ 20.11.15, 09:25

Угу. Именно так.

Супер аргумент.
Аргументированный так же ответ: нет, совсем не так.

Добавлено 20.11.15, 09:52
Отсутствие инициализации - UB. UB всегда плохо, потому что оно непредсказуемо.

[Flex Ferrum]

Поэтому надо бороться с отсутствием инициализации, а не делать её неявной. explicit is always better than implicit.

[applegame]

Цитата Flex Ferrum @ 20.11.15, 09:54

Поэтому надо бороться с отсутствием инициализации, а не делать её неявной. explicit is always better than implicit.

Это другая крайность. Безопасность в ущерб читабельности и удобству. Если уж выбирать implicit, то defined implicit, а не undefined implicit.

[D_KEY]

Цитата Flex Ferrum @ 20.11.15, 09:54

Поэтому надо бороться с отсутствием инициализации, а не делать её неявной.

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