@geza Вот такой вот совет, наверное. Я склонен читать такой совет как имеющий в виду «если у вас нет причин не делать этого». Часто я думаю, что люди осторожны с явным включением этих оговорок на случай, если новый программист может использовать эту логику для списания полезной функции. Кроме того, особенно для такого языка, как C ++, я думаю, что люди склонны отдавать предпочтение функциям, которые позволяют компилятору выполнять дополнительную работу за вас, и верят, что вы узнаете, что на самом деле означает ошибка, прежде чем продолжить, и посчитаете ее чистой выгодой в этом свете.

у много разных мест, где одинаковая инициализациярекомендуемые, Херб Саттеррекомендует это, и дает список, когдане использовать это. Кажется, что общее согласие состоит в том, чтобы использовать этот синтаксис.

Однако я не понимаю, почему. Это проблемаstd::initializer_list имеет приоритет. Добавлениеstd::initializer_list к классу может сломать код. С шаблонами использовать не рекомендуется. Кажется, есть больше исключений, чем «старый» способ. Ни одна из этих проблем не существовала по старинке.

Я не понимаю, почему равномерная инициализация лучше. Мой вывод заключается в том, чтобы продолжать использовать() синтаксис и использование{} только в случае, когда я хочу вызвать конструктор сstd::initializer_list.

Почему? Что дает равномерная инициализация?

запрещает сужение: хорошая особенность. Но, так как у меня сужаются предупреждения, включите длявсе мой код (потому что я хочу знать все сужения в моем коде, а не только при инициализации), мне не нужна эта функция слишком много.самый неприятный анализ: да, это проблема, но я сталкиваюсь с этим очень-очень редко. Так что это не повод (для меня) переключаться. Это места, я могу использовать{}.Есть ли что-нибудь еще (может быть, я все еще изучаю новые функции C ++)?

При «старом» способе не было никаких правил для запоминания, никакого возможного взлома кода. Просто используйте его, и иногда, очень-очень редко, вы попадаете в самый неприятный анализ. Вот и все.

Мое мышление где-то неправильно?

 nwp25 сент. 2017 г., 13:14
Это помогает узнать, какие вещи являются функциями, а какие - объектами.f(g(), h(j, i)); менее ясно, чемf(g{}, h(i, j));, Это все еще имеет значение, когда переменные имеют собственные имена.
 nwp25 сент. 2017 г., 13:49
Ваше соглашение об именах не соблюдается STL или различными другими библиотеками. Но, конечно, если вы замените большинство функций инициализированных скобок каким-либо внешним инструментом и будете работать в одиночку или заставлять всех вокруг делать то же самое, они вам не нужны. Не каждая функция C ++ имеет смысл для всех.
 geza25 сент. 2017 г., 13:35
@nwp: да, это правильный аргумент. Но у меня есть соглашение об именах, где я могу сразу увидеть типы. Кроме того, текущие хорошие IDE могут показывать разницу между ними какими-то способами (окраска, курсив, что угодно).

Ответы на вопрос(1)

nwp поднял другую проблему, которую я хотел бы упомянуть, ясность в комментариях. Поэтому я думаю, что у вас есть информация, необходимая для принятия решения.

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

И, честно говоря, похоже, что вы пытались решить эту проблему, придерживаясь стиля и инструментов, которые помогут решить эту проблему. Стандартный аргумент, какnwp Началось с того, что многие люди не согласны с отклонениями от соглашений об именах, встроенных в язык, или с использованием IDE. Я лично сочувствую этой логике, но также понимаю, почему многие игнорируют ее как старомодную или даже не относящуюся к делу (особенно в случае IDE).

Однако, когда дело доходит до ясности, мне трудно не иметь в виду, что люди досадно умеют игнорировать мелкие детали, даже если они могут им помочь. Таким образом, чем больше контекстных подсказок может подсказать, где проблема может быть, тем лучше. Подсветка синтаксиса великолепна, но я бы не поспорил на вечер отладки, когда смог заметить что-то желтое вместо оранжевого. Желтый и используется верблюжий чехол? Может быть. Желтый и использование брекетов? Может быть.

Особенно, когда вы начинаете проникать в код, написанный кем-то другим, или давным-давно, тем больше начинают действовать все эти маленькие подсказки.

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

Кроме того, примечание в ответ на ваш комментарий о сужении. Включение предупреждений для сужения может позволить вам пока игнорировать это преимущество, но во многих случаях люди либо 1) не могут включить такие предупреждения из-за унаследованного кода, либо 2) не хотят включать такие предупреждения, потому что они намеренно полагаются на такое поведение в определенные обстоятельства и будут рассматривать предупреждения как неприятность. Однако принятие инициализации списка в любом случае может помочь не только предотвратить потенциальные проблемы, но и прояснить цель данной строки кода.

Чтобы добраться до сути, все люди имеют разные обстоятельства и предпочтения. Такие функции, как это увеличение способов, которыми люди могут улучшить качество / удобочитаемость своего кода, все еще работая в рамках любых ограничений, которые они могут иметь (навязанные самим или иным образом).

 geza27 сент. 2017 г., 10:32
В общем, я с тобой согласен. Я просто не вижу проблемы здесь. Во многих случаях просто не имеет значения,a() это вызов функции или конструктор. Оба «возвращают» объект. Единственное, что я принимаю здесь, это то, что{} может помочь понять код чуть-чуть лучше. Но когда вы пытаетесь понять чужой код, вам лучше использовать инструменты для этого. Например, с помощью отладчика вы можете намного легче следовать по пути, по которому идет код, и т. Д. Ваша точка включения предупреждений для унаследованного кода абсолютно верна.
 geza27 сент. 2017 г., 10:34
Так что да, есть разные обстоятельства, предпочтения. Вот почему мне странно, что{} рассматривается как нечто превосходящее, и общий совет: «используйте это». На мой взгляд, этот совет должен быть изменен на что-то более сложное.
 thesquaregroot27 сент. 2017 г., 13:37
@geza Вот такой вот совет, наверное. Я склонен читать такой совет как имеющий в виду «если у вас нет причин не делать этого». Часто я думаю, что люди осторожны с явным включением этих оговорок на случай, если новый программист может использовать эту логику для списания полезной функции. Кроме того, особенно для такого языка, как C ++, я думаю, что люди склонны отдавать предпочтение функциям, которые позволяют компилятору выполнять дополнительную работу за вас, и верят, что вы узнаете, что на самом деле означает ошибка, прежде чем продолжить, и посчитаете ее чистой выгодой в этом свете.

Ваш ответ на вопрос