Это неоднозначно или прекрасно подходит это?
Этот код неоднозначен или прекрасно подходит это (утвержденный стандартами / последовательное поведение для каких-либо существующих компиляторов)?
struct SCustomData {
int nCode;
int nSum;
int nIndex;
SCustomData(int nCode, int nSum, int nIndex)
: nCode(nCode)
, nSum(nSum)
, nIndex(nIndex)
{}
};
править:
да, я обращаюсь к тому, что членские переменные имеют то же имя с формальными параметрами конструктора.
6 ответов
Нет, в этом случае нет неоднозначности, но рассмотрим следующее:
struct SCustomData {
//...
void SetCode(int nCode)
{
//OOPS!!! Here we do nothing!
//nCode = nCode;
//This works but still error prone
this->nCode = nCode;
}
};
Вы должны привлечь внимание к одному из существующих стилей кодирования. Например, правило общего именования в стилях кодирования Google C ++ или прочитать отличную книгу « Стандарты кодирования C ++: 101 правила, руководящие принципы и лучшие практики « Герб Саттер и Андрей Александреску.
Ваш пример недвусмысленнее (для меня), но это не очень хорошая практика, потому что он может быстро стать как администрации.
Это долгое время, поскольку я написал любой C ++ в гневе, поэтому я предполагаю, что сделает следующее.
Вы знаете Что это будет делать? Вы уверены, что?
class Noddy
{
int* i;
Noddy(int *i)
: i(i)
{
if(i == NULL)
i = new int;
}
};
В целом я префиксировал переменные экземпляра с подчерками и названными параметрами в конструкторе без каких-либо префиксов. По крайней мере, это подтвердит ваши параметры из ваших переменных экземпляров. Это также делает жизнь менее беспокойными при инициализации в организме конструктора.
struct SCustomData {
int _nCode;
int _nSum;
int _nIndex;
SCustomData(int nCode, int nSum, int nIndex)
: _nCode(nCode), _nSum(nSum), _nIndex(nIndex)
{}
};
// Alternatively
struct SCustomData {
int _nCode;
SCustomData(int nCode)
{
this->_nCode = nCode;
}
};
Я не люблю укладывать переменные, как это было написано в этом вопросе. Мне нравится сохранять вертикальное пространство, и мне также легче читать слева направо. (Это личное предпочтение моего, а не обязательное правило или что-то подобное.)
Я бы сказал, что это совершенно нормально.
Это мой предпочтительный стиль для конструкторов, которые используют список инициализации и не имеют никакого кода. Я думаю, что это уменьшает путаницу, потому что это очевидно, какой параметр конструктора идет к какому члену.
Он полностью совместим со стандартами, но есть компиляторов, которые не принимают переменные-члены, имеющие то же имя, что и параметры конструктора. Фактически, по этой причине мне пришлось изменить свою библиотеку с открытым исходным кодом. См. этот патч
Если вы имеете в виду использование одного и того же имени для членов и аргументов конструктора, то это абсолютно нормально. Однако вы можете найти людей, которые по какой-то причине настаивают на том, что это плохая практика.
Если вам нужно получить доступ к членам в теле конструктора, будьте осторожны - либо дайте аргументам разные имена, либо используйте this -> для доступа к членам.
Если вы имеете в виду использование псевдо-венгерских бородавок, чтобы напомнить людям, что целые числа являются целыми числами, то это технически разрешено, но не имеет абсолютно никаких преимуществ и затрудняет чтение кода. Пожалуйста, не делай этого.