Здравствуйте Aquary, Вы писали:
A>Здравствуйте achp, Вы писали:
A>>>>>Или я что-то упустил? DS>>>>Yah (Да, то есть ) A>>>Что? A>>Ошибка компиляции: переход в обход инициализации объекта.
A>Ты про что? откомпилил (изменив case 1 на case 2 ), заработало...
switch (variant)
{
case 1:
my_brilliant_class_that_desperately_needs_initialization x;
// ...break;
case 2:
// ...
}
Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
Здравствуйте achp, Вы писали:
A>>Ты про что? откомпилил (изменив case 1 на case 2 ), заработало...
A>
A>switch (variant)
A>{
A>case 1:
A> my_brilliant_class_that_desperately_needs_initialization x;
A> // ...
A> break;
A>case 2:
A> // ...
A>}
A>
A>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
A>>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
[skipped]
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
Здравствуйте Aquary, Вы писали:
F>>>А с кейсами как быть?
A>
DS>> case 1:
DS>> {
DS>> ...
DS>> break;
DS>> }
A>
A>там { } не нужны, просто не зачем
A>я пишу A>
A>switch (a) {
A> case 1:
A> //
A> break;
A> case 1:
A> //
A> break;
A> default:
A> //
A>} //switch (a)
A>
Если внутри ветки case есть переменная с нетривиальной инициализацией (класс с конструктором, переменная 'int' объявленная с инициализатором и т.п.) то без фигурных скобок ты получишь сообщение об ошибке компиляции.
A>>Несмотря на break объект x видим после метки case 2. Т. е. к нему можно обращаться, он там "живет". Но! В случае перехода к этой метке инициализация x остается обойденной, что компилятором и не допускается.
A>Это все правильно, только вот скажи — часто ли тебе приходится объявлять объекты класса внутри case? ИМХО, несколько некрасиво это... ИМХО...
Во-первых, мне, например, часто.
Во-вторых, это не обязятельно должен быть экземпляр класса. С обычным 'int i = 0;' будет то же самое — сообщение об ошибке компиляции.
АТ>Если внутри ветки case есть переменная с нетривиальной инициализацией (класс с конструктором, переменная 'int' объявленная с инициализатором и т.п.) то без фигурных скобок ты получишь сообщение об ошибке компиляции.
Да это все понятно я изначально имел в виду, что их там может и не быть по стандарту не более того
Конечно, в приведенных случаях, там обязаны быть и скобки.
Изначально другое интересно было — кто как форматирует это дело.
Cо скобками в первом стиле это будет
Здравствуйте Aquary, Вы писали:
A>Изначально другое интересно было — кто как форматирует это дело. A>Cо скобками в первом стиле это будет
A>
A>case 1: {
A> do1();
A> break;
A>}
A>case 2{
A> do2();
A> break;
A>}
A>
Я бы не называл все это "стилем программирования". К стилю программирования это никакого оотношения не имеет. Это скорее деталь стиля оформления исходных файлов. Я на практичке встречаю три стиля оформления:
if (expression) {
statement;
}
if (expression)
{
statement;
}
if (expression)
{
statement;
}
Я пользуюсь средним вариантом. Давно не встречал последнего, хотя на одной из предыдущих работ им пользовались многие. В ветках 'case' я ставлю фигурные скобки только если они там действительно нужны (ветка содержит обпределения локальных объектов).
Мне представляется разумным следующий стиль оформления исходников:
1. Фигурные скобки
{
// Фигурные скобки одна под другой
// Открывающая фигурная скобка всегда одинока на своей строчке, даже без комментария
}
Заключенное между фигурными скобками тело пространства имен первого уровня, кроме безымянного, не сдвигается, а вместо этого отбивается пустыми строками:
namespace имя
{
t f();
namespace вложенное
{
t1 f1();
}
}
namespace
{
t2 f2();
}
2. Циклы while и условные операторы
Если тело цикла или часть "то" или "иначе" условного оператора является чем-то иным, нежели оператором-выражением, оно заключается в фигурные скобки, даже если синтаксис этого не требует:
while (что-то)
{ // Синтаксис не требует здесь фигурных скобокif (нечто)
оператор-выражение
}
3. else, while после фигурной скобки
Ключевые слова else, а также while, относящееся к циклу do-while, располагаются на одной строке с фигурной скобкой, завершающей предшествующее им тело цикла или часть "то" условного оператора, ежели таковая наличествует:
if (что-то)
{
// Много чего
} else// Не является "самостоятельным", поэтому вслед за скобкой
// Черт-те что!
А также:
do
{
// Много чего
} while (что-то) // Не является "самостоятельным", поэтому вслед за скобкой
Здравствуйте achp, Вы писали:
A>Мне представляется разумным следующий стиль оформления исходников:
[тут сожрали демоны] A>Интересно было бы услышать критические замечания.
1. места много уходит на одиночные скобки на строке — это уже писали
2. вложенные namespace лучше смещать на 4 символа, как и все остальное — нагляднее.
Вообще, имхо, любые вложения лучше смешать — чтобв открывающий и закрывающий элемент были на одногй "линии" — лучше отслеживать, где начало и где конец блока.
Здравствуйте Aquary, Вы писали:
A>Здравствуйте Dr_Sh0ck, Вы писали: F>>>А с кейсами как быть?
A>
DS>> case 1:
DS>> {
DS>> ...
DS>> break;
DS>> }
A>
A>там { } не нужны, просто не зачем
A>я пишу A>
A>switch (a) {
A> case 1:
A> //
A> break;
A> case 1:
A> //
A> break;
A> default:
A> //
A>} //switch (a)
A>
Только вот "пустой" default не получится: компилятор ругается...
A>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям)
Здравствуйте Aquary, Вы писали:
A>Здравствуйте achp, Вы писали:
A>>Мне представляется разумным следующий стиль оформления исходников: A>[тут сожрали демоны] A>>Интересно было бы услышать критические замечания.
A>1. места много уходит на одиночные скобки на строке — это уже писали
Точно! У меня как раз места на диске не хватает: надо куда-то переписать 2 или 3 гигабайта видео, уже и болванки лежат, да все руки не доходят...
Здравствуйте The Lex, Вы писали:
TL>Только вот "пустой" default не получится: компилятор ругается...
Ну это я уже не стал дописывать — идею только демонстрировал
A>>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям) TL>Поддерживаю...
Это из Голуба, что ли... не помню... Кто-нибудь еще этим пользуется?
Здравствуйте Aquary, Вы писали:
A>Здравствуйте The Lex, Вы писали:
TL>>Только вот "пустой" default не получится: компилятор ругается... A>Ну это я уже не стал дописывать — идею только демонстрировал
A>>>последний комментарий //switch — если switch вылазит за пределы экрана (применяю также и к остальным конструкциям) TL>>Поддерживаю... A>Это из Голуба, что ли... не помню... Кто-нибудь еще этим пользуется?
Не, Голуба я не знаю. Это из моих исходников. А еще есть глупая привычка в конце функции ее название приписывать:
someType SomeFunction()
{
// Some code
// ...
} // Some Function
Потому как совсем невмоготу стараться вникнуть в то, "где начало этого конца". И размеры экрана тут не при чем: у меня сейчас 1024 высоты имеется — все равно сильно много задумываться лень — проще задокументировать. Не все подряд, конечно, но каждый хвост, претендующий на сколь бы то ни было порядочную длинну, следует подписать. Мое скромное мнение, разумеется...
C>Я использую стиль 1, но возможно есть идеи и лучьше?
В целях последующих изменений (а это почти всегда бывает нужно) лучше использовать {} — проще модифицировать программу. Да и AnyCondition бывает достаточно сложным, со скобками, да и многострочным. Так что 2). Хотя при быстром написании (посколько VC не делает автоматически {}) иногда получается вариант 1).
А>Какой стиль выбрать ? Мне кажется стиль 2 намного удобнее.
Здесь очень трудно говорить какой из стилей удобней, т.к. все сугубо индивидуально. Но, например, когда входишь в новую команду ,а у них уже куча кода с одним стилем (например с первым), то хочешь или не хочешь, а придется писть используя второй.
Это и есть самое главное в любых стилях — главное постоянство. Потому что любой программер привыкнет к чтению даже самого отвратного стиля, но если он будет использоваться на протяжении всего проекта.
Здравствуйте OlegO, Вы писали:
OO>Предлагаю всем вместо приведения различных ситуаций, почитать книгу Ален И.Голуб "Правила программирования на С++", там этой теме целая книга посвещена, с примерами и аргументами.
Где-то в этом же треде я уже предлагал разместить ее на сайте, чтоб далеко не ходить...