Здравствуйте, tarkil, Вы писали:
T>Сравни, например:
T>
currentDoc->_meta._apps[appIndex]._uid
currentDoc->meta.apps[appIndex].uid
T>Сложнее же первое читается?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, tarkil, Вы писали:
T>Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой?
С __двух или _Капс. _одиночное подчёркивание можно.
Во всяком случае, STL для VC вовсю использует _Капс для внутренних нужд.
Если не боишься случайно пересечься с ними и в каком-нибудь экзотическом случае сломать, например, ADL — то пожалуйста.
T>А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
Здравствуйте, tarkil, Вы писали:
T>Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой? T>А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
начинай с m_
это одно из немногих правил венгерки, которое реально удобно.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, tarkil, Вы писали:
T>Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой?
17.4.3.1.2
— Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase
letter (2.11) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.165)
Сноска 165
Such names are also reserved in namespace ::std (17.4.3.1).
В драфте C++0x это требование по-прежнему присутствует.
T>А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
Если после подчеркивания не стоит заглавная буква, то ничего страшного — такие имена запрещено использовать только в глобальном пространстве имен, и в пространстве std.
Кстати некоторые известные товарищи рекомендуют добавлять подчеркивание в конце имени члена )
>актуально или ушло в область преданий старины глубокой?
актуально: имена с двойным подчеркиванием и подчеркиванием в начале и следующей за ним uppercase letter — их вообще не стоит использовать. Имена, начинающиеся с подчеркивания — зарезервированы в пространстве имен стд и глобальном. В принципе, можно их использовать. Саттер что-то там такое говорил о возможности существования макросов с такими именами (мол им плевать на области видимости вообще), но это глупая мысль — тогда любое имя нельзя использовать — вдруг макрос??????
Of course, the code must be complete enough to compile and link.
Здравствуйте, tarkil, Вы писали:
T>Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой?
Пост Саттера http://www.gotw.ca/gotw/085.htm
T>А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
можно, если второй символ будет буквой в нижнем регистре.
Здравствуйте, Lorenzo_LAMAS, Вы писали:
J>>Так же, как нам не разрешается использовать имена с подчеркивания, так и им не разрешается использовать имена не с подчеркивания. L_L>не могу с ходу найти такого
вполне возможно, что такого формального требования и нету, если не понимать слово "зарезервированы" в этом смысле.
Но есть 2 факта:
1) имена с подчеркиванием зарезервированы для реализации (чтобы не было конфликтов и феерверков).
2) никто проблем (конфликтов и феерверков) на ровном месте создавать не будет, тем более если их легко избежать.
Имхо, этого достаточно, чтоб чувствовать себя спокойно на счет "любых имен" и использовать имена не с подчеркивания без опаски.
Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой?
А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
Здравствуйте, tarkil, Вы писали:
T>Коллеги, а вот правило «не начинайте свои идентификаторы с подчёркивания, ибо зарезервировано под системные имена» — оно ещё актуально или ушло в область преданий старины глубокой?
T>А то нестатические поля классов уж очень удобно с подчёркивания начинать. Но опасаюсь.
ничего не изменилось
16.8 Predefined macro names
....
3 The values of the predefined macros (except for _ _ FILE _ _ and _ _ LINE _ _) remain constant throughout
the translation unit.
4 If any of the pre-defined macro names in this subclause, or the identifier defined, is the subject of a #define
or a #undef preprocessing directive, the behavior is undefined. Any other predefined macro names shall begin
with a leading underscore followed by an uppercase letter or a second underscore.
17.6.3.3.2 Global names [global.names]
1 Certain sets of names and function signatures are always reserved to the implementation:
— Each name that contains a double underscore _ _ or begins with an underscore followed by an uppercase
letter (2.12) is reserved to the implementation for any use.
— Each name that begins with an underscore is reserved to the implementation for use as a name in the
global namespace.
Здравствуйте, Bell, Вы писали:
B>В драфте C++0x это требование по-прежнему присутствует.
Это важно: значит считают по-прежнему актуальным.
B>Если после подчеркивания не стоит заглавная буква, то ничего страшного — такие имена запрещено использовать только в глобальном пространстве имен, и в пространстве std.
Ага, спасибо.
B>Кстати некоторые известные товарищи рекомендуют добавлять подчеркивание в конце имени члена )
Здравствуйте, Lorenzo_LAMAS, Вы писали:
>>актуально или ушло в область преданий старины глубокой?
L_L>актуально: имена с двойным подчеркиванием и подчеркиванием в начале и следующей за ним uppercase letter — их вообще не стоит использовать. Имена, начинающиеся с подчеркивания — зарезервированы в пространстве имен стд и глобальном. В принципе, можно их использовать. Саттер что-то там такое говорил о возможности существования макросов с такими именами (мол им плевать на области видимости вообще), но это глупая мысль — тогда любое имя нельзя использовать — вдруг макрос??????
Нет, не любое, а только начинающееся с подчеркивания.
Так же, как нам не разрешается использовать имена с подчеркивания, так и им не разрешается использовать имена не с подчеркивания.
J>Так же, как нам не разрешается использовать имена с подчеркивания, так и им не разрешается использовать имена не с подчеркивания.
не могу с ходу найти такого
Of course, the code must be complete enough to compile and link.
J>Но есть 2 факта: J>1) имена с подчеркиванием зарезервированы для реализации (чтобы не было конфликтов и феерверков). J>2) никто проблем (конфликтов и феерверков) на ровном месте создавать не будет, тем более если их легко избежать. J>Имхо, этого достаточно, чтоб чувствовать себя спокойно на счет "любых имен" и использовать имена не с подчеркивания без опаски.
посмотрел кстати сейчас макросы в своей стд библиотеке — все с подчеркивания
Of course, the code must be complete enough to compile and link.
Непубличные поля (private, protected и protected internal) именуются в стиле Кэмел и начинаются с префикса _.
Оттуда же:
// Надо так:int _var1;
int _var2;
...
Если мне не изменяет память, некоторые товарищи стилем Кэмэл именуют идентификаторы типа CamelCase, если с ними согласиться, то этот пример тогда выглядел бы как
int _Var1;
, что нарушило бы требования стандарта.
Люди! Люди, смотрите, я сошел с ума! Люди! Возлюбите друг друга! (вы чувствуете, какой бред?)
Здравствуйте, Кодт, Вы писали:
К>С __двух или _Капс. _одиночное подчёркивание можно.
К>Во всяком случае, STL для VC вовсю использует _Капс для внутренних нужд.
Так потому и использует, чтобы исключить пересечение с пользовательскими макросами. И имеет на это право (стандартная библеотека является частью implementation).
Здравствуйте, rusted, Вы писали:
К>>Во всяком случае, STL для VC вовсю использует _Капс для внутренних нужд.
R>Так потому и использует, чтобы исключить пересечение с пользовательскими макросами. И имеет на это право (стандартная библеотека является частью implementation).
О том и речь. Разработчики компилятора заботятся о том, чтобы не пересечься с пользователями, а пользователи должны позаботиться, чтобы не пересечься с компилятором. А граница проведена в стандарте.
Здравствуйте, Кодт, Вы писали:
К>О том и речь. Разработчики компилятора заботятся о том, чтобы не пересечься с пользователями, а пользователи должны позаботиться, чтобы не пересечься с компилятором. А граница проведена в стандарте.
как же мне хочется чтобы разработчики компиляторов использовали для этих случаев префикс xx_ или какой нибудь другой, но не с подчеркивания.
имеет две группы людей которые претендуют на _ в начале слова: обычные и разработчики компиляторов.
Обычная группа больше, но она проигрывает.
Здравствуйте, slava_phirsov, Вы писали:
_>Если мне не изменяет память, некоторые товарищи стилем Кэмэл именуют идентификаторы типа CamelCase, если с ними согласиться, то этот пример тогда выглядел бы как
camelCase тоже...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Feonyf, Вы писали:
F>как же мне хочется чтобы разработчики компиляторов использовали для этих случаев префикс xx_ или какой нибудь другой, но не с подчеркивания.
В свое время Борланд использовал префикс T, а разработчики MFC использовали префикс C.
Теперь каждый второй изобретает CMyCoolClass, а каждый третий — TMyCoolClass
Почему вы бам не последовать своему примеру? У нас, к примеру в конторе весь API начинается с хх_ (правда, скорее всего потму что написан на С . Это нисколько не страшно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1284>>
Каждый, просыпаясь утром, должен задавать себе вопрос — что он может сегодня сделать, чтобы россиянства
Перекуём баги на фичи!
, в RSDN coding style:
