Стиль декларирования челенов класса - Философия программирования

Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

Здравствуйте, FurJ, Вы писали:

FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

Нормально все применимо. Ты все равно не угадаешь. Вот у нас был свой контейнер CStringBuf, а потом вышел ATL7.0, где появился с таким же именем — и все, наш пришлось переименовать.

Здравствуйте, FurJ, Вы писали:

FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_". Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

Вроде бы МС и для C# не рекомендует начинать идентификаторы с подчеркивания из соображений совместимости

Здравствуйте, FurJ, Вы писали:

ээээ...
с нижнего регистра начинаются имена любых переменных..
с верхнего — функций..
а имена переменных-членов (класса) должны еще заканчиваться _ (подчеркиванием)

кстати "альтернативная" типа была предложена г.саттером.....

Здравствуйте, FurJ, Вы писали:

FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_".

Нет. Венгерка предполагает не просто префикс, а префикс, отражающий тип.

FJ> Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания.

В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. А в C# разные стили бывают, в том числе и с m_.

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, smidy, Вы писали:

S>а имена переменных-членов (класса) должны еще заканчиваться _ (подчеркиванием)

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

Здравствуйте, AndrewVK, Вы писали:

AVK>Нет. Венгерка предполагает не просто префикс, а префикс, отражающий тип — согласен, просто я это опустил, поскольку к сути вопроса это отношения не имеет.

AVK>В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. — к сожелению не видел документа от Sun (можно ссылку?), но замечал что этот стиль у большинства Java-программеров (Фаулер — самый яркий представитель).

Здравствуйте, FurJ, Вы писали:

FJ>для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).

Таким образом можно смело называть член класса именем типа _мАленькаяБуква?

FJ>Таким образом можно смело называть член класса именем типа _мАленькаяБуква?

В С++ лучше не стоит. Саттер говорит, мол, что мешает реализации определить макрос с таким именем?

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>В С++ лучше не стоит. Саттер говорит, мол, что мешает реализации определить макрос с таким именем?

Понятно. Спасибо.

Здравствуйте, FurJ, Вы писали:

AVK>>В Java стиль описан документом от Sun.

FJ>Подчеркивания я там что то не припомню. — к сожелению не видел документа от Sun (можно ссылку?), но замечал что этот стиль у большинства Java-программеров (Фаулер — самый яркий представитель).

http://developers.sun.com/software/sundev/whitepapers/java-style.pdf

Field naming
Names of non-constant fields (reference types, or non-final primitive types) should use the infixCaps style.
Start with a lower-case letter, and capitalize the first letter of any subsequent word in the name, as well as
any letters that are part of an acronym. All other characters in the name are lower-case. Do not use underscores
to separate words. The names should be nouns or noun phrases. Examples:
boolean resizable;
char recordDelimiter;

P.S. И цитируй, пожалуйста, как следует.

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, AndrewVK, Вы писали:

AVK>http://developers.sun.com/software/sundev/whitepapers/java-style.pdf

Спасибо, нашел. Правда, похоже местоположение документа изменилось на
http://developers.sun.com/prodtech/cc/products/archive/whitepapers/java-style.pdf

Здравствуйте, Lorenzo_LAMAS, Вы писали:

L_L>Здравствуйте, FurJ, Вы писали:

FJ>>для C++ — программирования? Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

L_L>Имена, начинающиеся с __ или _Большая буква — зарезервированы. Имя, начинающееся с подчеркивания зарезервировано в глобальном пространстве имен (и пространстве имен ::std).

Точнее, зарезервированы имена содержащие __, в начале или нет — не важно.

На мой взгляд, стиль m_nnn — это вполне разумно. Собственно, это единственное, что я активно использую из старых MS-рекомендаций. А в C# его явно или неявно душат (дизайнером форм, например). Типа раньше всех убеждали, как "m_" и венгерская нотация полезны для здоровья, а теперь это стало не вкусно, выплюньте.

Что же касается подчеркиваний, то начинать или заканчивать ими — это полный атас. Мало того, что может потенциально привести к конфликтам, так еще и код весь превращается в крокозяблики.

        if (_End - _Last < _M)
            {size_type _N = size() + (_M < size() ? size() : _M);
            iterator _S = allocator.allocate(_N, (void *)0);
            iterator _Q = _Ucopy(_First, _P, _S);
            _Q = _Ucopy(_F, _L, _Q);
            _Ucopy(_P, _Last, _Q);
            _Destroy(_First, _Last);
            allocator.deallocate(_First, _End - _First);
            _End = _S + _N;
            _Last = _S + size() + _M;
            _First = _S; }
        else if (_Last - _P < _M)
            {_Ucopy(_P, _Last, _P + _M);
            _Ucopy(_F + (_Last - _P), _L, _Last);
            copy(_F, _F + (_Last - _P), _P);
            _Last += _M; }
        else if (0 < _M)
            {_Ucopy(_Last - _M, _Last, _Last);
            copy_backward(_P, _Last - _M, _Last);
            copy(_F, _L, _P);
            _Last += _M; }}

Лично у меня от такого рябит в глазах и болит голова.
По моему глубокому убеждению, идентификаторы должны начинаться и заканчиваться буквами. Прописными или строчными, но буквами. Подчеркивания допустимы (и даже необходимы) внутри идентификатора, но не по краям. В этом случае, идентификаторы гораздо легче визуально отделяются от знаков препинания (операций) — как в обычном, естественном тексте. Иначе неизбежно полявляются brainfuck-шедевры типа:

_a_-_b_._c_->_d_

Здравствуйте, McSeem2, Вы писали:

MS>Что же касается подчеркиваний, то начинать или заканчивать ими — это полный атас. Мало того, что может потенциально привести к конфликтам, так еще и код весь превращается в крокозяблики.
MS>

MS>        if (_End - _Last < _M)
MS>            {size_type _N = size() + (_M < size() ? size() : _M);
MS>            iterator _S = allocator.allocate(_N, (void *)0);
MS>            iterator _Q = _Ucopy(_First, _P, _S);
MS>            _Q = _Ucopy(_F, _L, _Q);
MS>            _Ucopy(_P, _Last, _Q);
MS>            _Destroy(_First, _Last);
MS>            allocator.deallocate(_First, _End - _First);
MS>            _End = _S + _N;
MS>            _Last = _S + size() + _M;
MS>            _First = _S; }
MS>        else if (_Last - _P < _M)
MS>            {_Ucopy(_P, _Last, _P + _M);
MS>            _Ucopy(_F + (_Last - _P), _L, _Last);
MS>            copy(_F, _F + (_Last - _P), _P);
MS>            _Last += _M; }
MS>        else if (0 < _M)
MS>            {_Ucopy(_Last - _M, _Last, _Last);
MS>            copy_backward(_P, _Last - _M, _Last);
MS>            copy(_F, _L, _P);
MS>            _Last += _M; }}
MS>

На самом деле любую нотацию можно довести до brainfuck-a. Замени в этом примере подчеркивание на "m_" — в глазах будет рябить не меньше.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Воронков Василий, Вы писали:

ВВ>На самом деле любую нотацию можно довести до brainfuck-a. Замени в этом примере подчеркивание на "m_" — в глазах будет рябить не меньше.

Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).

        if (m_End - m_Last < m_M)
            {sizem_type m_N = size() + (m_M < size() ? size() : m_M);
            iterator m_S = allocator.allocate(m_N, (void *)0);
            iterator m_Q = m_Ucopy(m_First, m_P, m_S);
            m_Q = m_Ucopy(m_F, m_L, m_Q);
            m_Ucopy(m_P, m_Last, m_Q);
            m_Destroy(m_First, m_Last);
            allocator.deallocate(m_First, m_End - m_First);
            m_End = m_S + m_N;
            m_Last = m_S + size() + m_M;
            m_First = m_S; }
        else if (m_Last - m_P < m_M)
            {m_Ucopy(m_P, m_Last, m_P + m_M);
            m_Ucopy(m_F + (m_Last - m_P), m_L, m_Last);
            copy(m_F, m_F + (m_Last - m_P), m_P);
            m_Last += m_M; }
        else if (0 < m_M)
            {m_Ucopy(m_Last - m_M, m_Last, m_Last);
            copym_backward(m_P, m_Last - m_M, m_Last);
            copy(m_F, m_L, m_P);
            m_Last += m_M; }}

Здравствуйте, McSeem2, Вы писали:

MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).
MS>

MS>        if (m_End - m_Last < m_M)
MS>            {sizem_type m_N = size() + (m_M < size() ? size() : m_M);
MS>            iterator m_S = allocator.allocate(m_N, (void *)0);
MS>            iterator m_Q = m_Ucopy(m_First, m_P, m_S);
MS>            m_Q = m_Ucopy(m_F, m_L, m_Q);
MS>            m_Ucopy(m_P, m_Last, m_Q);
MS>            m_Destroy(m_First, m_Last);
MS>            allocator.deallocate(m_First, m_End - m_First);
MS>            m_End = m_S + m_N;
MS>            m_Last = m_S + size() + m_M;
MS>            m_First = m_S; }
MS>        else if (m_Last - m_P < m_M)
MS>            {m_Ucopy(m_P, m_Last, m_P + m_M);
MS>            m_Ucopy(m_F + (m_Last - m_P), m_L, m_Last);
MS>            copy(m_F, m_F + (m_Last - m_P), m_P);
MS>            m_Last += m_M; }
MS>        else if (0 < m_M)
MS>            {m_Ucopy(m_Last - m_M, m_Last, m_Last);
MS>            copym_backward(m_P, m_Last - m_M, m_Last);
MS>            copy(m_F, m_L, m_P);
MS>            m_Last += m_M; }}

MS>

Ну что я могу сказать — brainfuck он и есть brainfuck.

Кому нравится спереди, кому-то — сзади...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

MS>        if (m_End - m_Last < m_M)
MS>            {sizem_type m_N = size() + (m_M < size() ? size() : m_M);
MS>            iterator m_S = allocator.allocate(m_N, (void *)0);
MS>            iterator m_Q = m_Ucopy(m_First, m_P, m_S);
MS>            m_Q = m_Ucopy(m_F, m_L, m_Q);
MS>            m_Ucopy(m_P, m_Last, m_Q);
MS>            m_Destroy(m_First, m_Last);
MS>            allocator.deallocate(m_First, m_End - m_First);
MS>            m_End = m_S + m_N;
MS>            m_Last = m_S + size() + m_M;
MS>            m_First = m_S; }
MS>        else if (m_Last - m_P < m_M)
MS>            {m_Ucopy(m_P, m_Last, m_P + m_M);
MS>            m_Ucopy(m_F + (m_Last - m_P), m_L, m_Last);
MS>            copy(m_F, m_F + (m_Last - m_P), m_P);
MS>            m_Last += m_M; }
MS>        else if (0 < m_M)
MS>            {m_Ucopy(m_Last - m_M, m_Last, m_Last);
MS>            copym_backward(m_P, m_Last - m_M, m_Last);
MS>            copy(m_F, m_L, m_P);
MS>            m_Last += m_M; }}
MS>

Ты с P.J. Plauger'ом тягаться не пробовал?

MS>        if (m_End - m_Last < m_M)
MS>            {sizem_type m_N = size() + (m_M < size() ? size() : m_M);
MS>            iterator m_S = allocator.allocate(m_N, (void *)0);
MS>            iterator m_Q = m_Ucopy(m_First, m_P, m_S);
MS>            m_Q = m_Ucopy(m_F, m_L, m_Q);
MS>            m_Ucopy(m_P, m_Last, m_Q);
MS>            m_Destroy(m_First, m_Last);
MS>            allocator.deallocate(m_First, m_End - m_First);
MS>            m_End = m_S + m_N;
MS>            m_Last = m_S + size() + m_M;
MS>            m_First = m_S; }
MS>        else if (m_Last - m_P < m_M)
MS>            {m_Ucopy(m_P, m_Last, m_P + m_M);
MS>            m_Ucopy(m_F + (m_Last - m_P), m_L, m_Last);
MS>            copy(m_F, m_F + (m_Last - m_P), m_P);
MS>            m_Last += m_M; }
MS>        else if (0 < m_M)
MS>            {m_Ucopy(m_Last - m_M, m_Last, m_Last);
MS>            copym_backward(m_P, m_Last - m_M, m_Last);
MS>            copy(m_F, m_L, m_P);
MS>            m_Last += m_M; }}

MS>

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

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

    if (_end - _last < _m)
    {
        size_type n = size() + (_m < size() ? size() : _m);
        iterator s = allocator.allocate(n, (void *)0);
        iterator q = Ucopy(_First, _p, s);
    
        q = Ucopy(_f, _l, q);
    
        Ucopy(_p, _last, q);
        Destroy(_First, _last);
        allocator.deallocate(_first, _end - _First);
        _end = s + n;
        _last = s + size() + _m;
        _first = s;
    }
    else if (_last - _p < _m)
    {
        Ucopy(_p, _last, _p + _m);
        Ucopy(_f + (_last - _p), _l, _last);
        copy(_f, _f + (_last - _p), _p);
        _last += _m;
    }
    else if (0 < _m)
    {
        Ucopy(_last - _m, _last, _last);
        copy_backward(_p, _last - _m, _last);
        copy(_f, _l, _p);
        _last += _m; 
    }
}

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

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

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

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, FurJ,

А я на (C#):

Переменные члены класса (в т.ч. статические) называю маленькими буквами: channel, handler, recognizer;

Локальные переменные (с маленькой областью видимости) обозначаю 1-2 буквами: a, b, c, s, h, i, j, n, rd, wr...;

Типы, процедуры, свойства, элементы enum-ов начинаю с большой буквы (а интерфейсы с I): Channel, Handler, IReader, IWriter,...;

Константы пишу заглавными буквами: MIN_LENGTH

При обращении к любым идентификаторам пишу их полное имя:

this.*** — обращение к членам;

MyClass.*** — обращение к статическим членам;

Namespace1.Namespace2.Namespace3.SomeClass1.*** — обращение ко всему, что за пределами данного класса.

Короче, получается так, что глядя даже на небольшой фрагмент текста (заранее не зная, что обозначают идентификаторы) — становится понятно что написано. Всегда!

Плюсовики видевшие мои тексты сразу спрашивали почему у меня везде написано: this.***, this.***, this.***? Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.

Здравствуйте, McSeem2, Вы писали:

MS>По моему глубокому убеждению, идентификаторы должны начинаться и заканчиваться буквами. Прописными или строчными, но буквами. Подчеркивания допустимы (и даже необходимы) внутри идентификатора, но не по краям. В этом случае, идентификаторы гораздо легче визуально отделяются от знаков препинания (операций) — как в обычном, естественном тексте. Иначе неизбежно полявляются brainfuck-шедевры типа:
MS>

MS>_a_-_b_._c_->_d_
MS>

А мне что-то другое напоминает

Сам для членов класса использую префикс m_. Привычно, хотя и избыточно слегка. В последнее время в C++ модно стало завершающее подчеркивание использовать (в ACE, например, это вообще стандарт кодирования), но меня смущает, чть если к члену через точку к методу какому-то обращаться, то эта точка получается не очень заметна визуальна (особенно, если в редакторе пропорциональный шрифт используется).

А одновременное использование лидирующего и заверщающего подчеркивания действительно неудобоваримые комбинации могут образовывать:

predictor( 0, gr_.rules_[ states_[ 0 ].items_[ _item_index ].rule_index_ ].right_part_[ states_[ 0 ].items_[ _item_index ].dot_pos_ ] );

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.
Сергей! А как же синтаксический оверхед?

Здравствуйте, AndrewVK, Вы писали:

AVK>В Java стиль описан документом от Sun. Подчеркивания я там что то не припомню. А в C# разные стили бывают, в том числе и с m_.
Стили то разные. Но префикс m_, насколько я помню, был явно запрещен в рекомендательном порядке.

Здравствуйте, GlebZ, Вы писали:

GZ>Стили то разные. Но префикс m_, насколько я помню, был явно запрещен в рекомендательном порядке.

Что не помешало им самим его использовать в некоторых классах фреймворка.

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, GlebZ, Вы писали:

GZ>Сергей! А как же синтаксический оверхед?

Он отсутствует.
Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка. Записывая так:

"идентификатор объекта"."идентификатор члена"

мы получаем то, что нам было нужно, и платим за это минимальную цену.
Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:

PROCEDURE (me: MyObject) DoSmth* (arg: Arg), NEW, EXTENSIBLE;
BEGIN me.value := arg
END DoSmth;

Здесь me — играет роль this (можно называть как хочется: me, self, this, p, q,..., я,... — это просто имя 0-вого аргумента вызова
процедуры связанной с типом MyObject).

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка.
Зачем? И так понятно.

СГ>Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:
Брр. Г-н Вирт что, Турбо-Паскаль не учил?

Синтаксический оверхед однозначна.

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

Здравствуйте, GlebZ, Вы писали:

GZ>...Пацаны такой текст не поймут.

Всегда писать this — признак дисциплинированности.

пацаны & дисциплинированность = mutual exclusion

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Всегда писать this — признак дисциплинированности.
Этот код не пацан писал. А генерировал автоматизированный resharper.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>А я на (C#):
СГ>

Переменные члены класса (в т.ч. статические) называю маленькими буквами: channel, handler, recognizer;
СГ>

Локальные переменные (с маленькой областью видимости) обозначаю 1-2 буквами: a, b, c, s, h, i, j, n, rd, wr...;
СГ>

Типы, процедуры, свойства, элементы enum-ов начинаю с большой буквы (а интерфейсы с I): Channel, Handler, IReader, IWriter,...;
СГ>

Константы пишу заглавными буквами: MIN_LENGTH

СГ>При обращении к любым идентификаторам пишу их полное имя:
СГ>

this.*** — обращение к членам;
СГ>

MyClass.*** — обращение к статическим членам;
СГ>

Namespace1.Namespace2.Namespace3.SomeClass1.*** — обращение ко всему, что за пределами данного класса.

Если придерживаться 3 простых правил, то путаницы не будет:
1. функции не больше 2 экранов.
2. глобальным объектам — строгое нет.
3. локальные переменные объявлять непосредственно перед использованием.

СГ>Короче, получается так, что глядя даже на небольшой фрагмент текста (заранее не зная, что обозначают идентификаторы) — становится понятно что написано. Всегда!

Утешай себя

Просто так, добавляя лишь this, понятность не вырастет, если код изначально корявый.

СГ>Плюсовики видевшие мои тексты сразу спрашивали почему у меня везде написано: this.***, this.***, this.***? Неужели, говорят, в C# слово this надо обязательно писать? Отвечал, что не обязательно, но я его всегда пишу потому что я дисциплинированный.

Нет, это — неуместное занудство, а не дисциплина. И достаточно чтобы посторонний человек поработал с таким кодом чуть-чуть и кое-где забыл написать this, все, целостность нарушена и дальше тебя будут вспоминать только недобрыми словами.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Он отсутствует.
СГ>Надо же как-то указать на то что идентификатор принадлежит объекту, а не взят с потолка. Записывая так:

СГ>"идентификатор объекта"."идентификатор члена"

СГ>мы получаем то, что нам было нужно, и платим за это минимальную цену.
СГ>Кстати, например, в языках Oberon-2 и Component Pascal аналог this надо писать обязательно:
А, то есть минимальная цена = (цене в Oberon-2 и Component Pascal) по определению?

Минимальная цена — не указывать лишних квалификаторов. Несложные правила именования позволяют не натыкаться на конфликты между именами параметров, переменными, и полями.

1.1.4 stable rev. 510

Здравствуйте, VladD2, Вы писали:

MS>>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).

VD>Если твой код отформатировать в соотвествии с предложением твоий оппонентов, то он будет выглядеть примерно так:

[. . .]
Я специально сделал оговорку, что "прочие аспекты не рассматриваем".

VD>Кстати, со своим экстровагантным выделением скобок и стремлением сжать все в кучу, ты потерял скобку.

Код не мой, Copyright (c) 1995 by P.J. Plauger. Это copy-paste куска из std::vector. Я его привел, чтобы показать всю несуразность, когда сначала возникают некие догмы, а потом они доводятся до полного абсурда.
STLPort, кстати, не лучше

pointer __tmp = _M_allocate_and_copy(__xlen, __CONST_CAST(const_pointer, __x._M_start) + 0,
                                             __CONST_CAST(const_pointer, __x._M_finish) + 0);
_M_clear();
this->_M_start = __tmp;
this->_M_end_of_storage._M_data = this->_M_start + __xlen;

Тот же самый brainfuck и спереди и сзади, похожий на азбуку Морзе. Плюс ко всему, в нем присутствуют строки неимоверной длины. Но эту тему мы не будем развивать.

За потерянную скобку приношу наиглубочайшие извинения и проч.

Здравствуйте, McSeem2, Вы писали:

MS>Код не мой, Copyright (c) 1995 by P.J. Plauger.

Ну, вот прими к сведению, что то о чем с тобой говорят и то что делает Plauger — это две большие разницы.

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, GlebZ, Вы писали:

GZ>Этот код не пацан писал. А генерировал автоматизированный resharper.

Не resharper, а reflector! Это немного разнае программы.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, McSeem2, Вы писали:

MS>Код не мой, Copyright (c) 1995 by P.J. Plauger. Это copy-paste куска из std::vector.

Я так и думал. Его стиль ни с чем не спутаешь.

Здравствуйте, FurJ, Вы писали:

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

Любые имена, содержащие двойное подчеркивание, зарезервированы за компилятором (и реализацией стандартной библиотеки, что одно и то же).

Имена, начинающиеся с подчеркивания и заглавной буквы зарезервированы в глобальном и std нэймспейсах.

(17.4.3.1.2)

Вот страница, на которой описано, что нельзя пользовать из имен.

Здравствуйте, aik, Вы писали:

aik>Нет, это — неуместное занудство, а не дисциплина. И достаточно чтобы посторонний человек поработал с таким кодом чуть-чуть и кое-где забыл написать this, все, целостность нарушена и дальше тебя будут вспоминать только недобрыми словами.

Да ладно. Alt+Ctrl+O и все дела

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>На самом деле любую нотацию можно довести до brainfuck-a. Замени в этом примере подчеркивание на "m_" — в глазах будет рябить не меньше.

MS>Именно так иногда и делаю. По крайней мере, становятся видны операции (прочие аспекты кодирования в данном примере мы не рассматриваем).
MS>

MS>        if (m_End - m_Last < m_M)
MS>            {sizem_type m_N = size() + (m_M < size() ? size() : m_M);
MS>            iterator m_S = allocator.allocate(m_N, (void *)0);
MS>            iterator m_Q = m_Ucopy(m_First, m_P, m_S);
MS>            m_Q = m_Ucopy(m_F, m_L, m_Q);
MS>            m_Ucopy(m_P, m_Last, m_Q);
MS>            m_Destroy(m_First, m_Last);
MS>            allocator.deallocate(m_First, m_End - m_First);
MS>            m_End = m_S + m_N;
MS>            m_Last = m_S + size() + m_M;
MS>            m_First = m_S; }
MS>        else if (m_Last - m_P < m_M)
MS>            {m_Ucopy(m_P, m_Last, m_P + m_M);
MS>            m_Ucopy(m_F + (m_Last - m_P), m_L, m_Last);
MS>            copy(m_F, m_F + (m_Last - m_P), m_P);
MS>            m_Last += m_M; }
MS>        else if (0 < m_M)
MS>            {m_Ucopy(m_Last - m_M, m_Last, m_Last);
MS>            copym_backward(m_P, m_Last - m_M, m_Last);
MS>            copy(m_F, m_L, m_P);
MS>            m_Last += m_M; }}

MS>

Такому стилю, кстати, есть интересное объяснение: http://groups.google.com/group/comp.lang.c++.moderated/msg/d2187ad2f05682e8?dmode=source&hl=en

Здравствуйте, McSeem2, Вы писали:

MS>STLPort, кстати, не лучше
MS>

MS>pointer __tmp = _M_allocate_and_copy(__xlen, __CONST_CAST(const_pointer, __x._M_start) + 0,
MS>                                             __CONST_CAST(const_pointer, __x._M_finish) + 0);
MS>_M_clear();
this->>_M_start = __tmp;
this->>_M_end_of_storage._M_data = this->_M_start + __xlen;
MS>

MS>Тот же самый brainfuck и спереди и сзади, похожий на азбуку Морзе.

Что тебе не нравится? Двойное подчёркивание?

Здравствуйте, aik, Вы писали:

aik>...кое-где забыл написать this...

Да, есть такое дело. Использование this по желанию — проблема языков C#, Delphi, и т.п.

В Oberon-2 и в Component Pascal эквивалент this писать надо обязательно.

Здравствуйте, AndrewVK, Вы писали:

AVK>Да ладно. Alt+Ctrl+O и все дела

А если текст распечатан на бумаге?

Здравствуйте, Сергей Губанов, Вы писали:

СГ>А если текст распечатан на бумаге?

А нафига бумагу переводить?

... << RSDN@Home 1.2.0 alpha rev. 631>>

Здравствуйте, alexeiz, Вы писали:

A>Что тебе не нравится? Двойное подчёркивание?

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

Здравствуйте, McSeem2, Вы писали:

A>>Что тебе не нравится? Двойное подчёркивание?
MS>Ну да. Я честно не понимаю, зачем все аргументы функций и все локальные переменные начинать с двойного подчеркивания. Это чисто мусор, без малейшей реальной пользы.
Это из-за препроцессора. Чтобы конфликта имен небыло.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, McSeem2, Вы писали:

A>>>Что тебе не нравится? Двойное подчёркивание?
MS>>Ну да. Я честно не понимаю, зачем все аргументы функций и все локальные переменные начинать с двойного подчеркивания. Это чисто мусор, без малейшей реальной пользы.
WH>Это из-за препроцессора. Чтобы конфликта имен небыло.

Точно. Агрумент такой, что ты можешь определить макро совпадающее с идентификатором из стандартной библиотеки перед включением хедеров из библиотеки. И тогда она сломается. Если же библиотека использует только зарезервированные имена идентификаторов, которые ты по стандарту не имеешь права определять, то ты защищён от подобного конфликта.

Здравствуйте, FurJ, Вы писали:

FJ>Существующая сегодня венгерская нотация предлагает для всех переменных членов класса ставить префикс "m_".

Много смеялся, спасибо. Почуял ностальгию.

FJ>Альтернативная рекомендация, завоевавшая мир C# и Java, предлагает названия приватных членов начинать с нижнего подчеркивания. Подобный стиль нередко встречается и у Unix-программистов. Насколько применима данная рекомендация для C++ — программирования?

Хочешь — применяй. Не хочешь — не применяй. Как ты думаешь, насколько важно ходить на работу в малиновых штанах если ты не менеджер?

FJ>Вопрос вызван в связи с непроверенной информацией будто бы в стандарте C++ token-ы, начинающиеся с нижнего подчеркивания, зарезервированы за компилятором.

Да, зарезериврованы.

Но!

Ответ вызван в связи твоего вопроса. Блин. Да. Вот. Десять. Рекомендую учить РУССКИЙ!

	От:	FurJ
	Дата:	24.01.06 14:17
	Оценка:

	От:	aik
	Дата:	24.01.06 14:19
	Оценка:

	От:	Ведмедь
	Дата:	24.01.06 14:30
	Оценка:

	От:	smidy
	Дата:	24.01.06 14:47
	Оценка:

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	24.01.06 14:53
Оценка:

	От:	Lorenzo_LAMAS
	Дата:	24.01.06 15:03
	Оценка:	+1

От:	McSeem2	http://www.antigrain.com
Дата:	24.01.06 22:06
Оценка:	3 (2) +2

	От:	Воронков Василий
	Дата:	24.01.06 22:48
	Оценка:	+3

От:	VladD2	www.nemerle.org
Дата:	25.01.06 02:04
Оценка:	1 (1) +5

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	25.01.06 08:21
Оценка:

От:	eao197	http://eao197.blogspot.com
Дата:	25.01.06 10:14
Оценка:	+2

От:	Sinclair	https://github.com/evilguest/
Дата:	25.01.06 13:35
Оценка:

От:	Kaa	http://blog.meta.ua/users/kaa/
Дата:	26.01.06 10:57
Оценка:

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	27.01.06 23:06
Оценка:

От:	c-smile	http://terrainformatica.com
Дата:	27.01.06 23:48
Оценка:	24 (1) +1