В C ++ это & ldquo; const & rdquo; после идентификатора типа приемлемо?
Общая информация теряется во время выполнения. Существует не эквивалент времени исполнения Creator & lt; String> .class. Вы можете создать тип между Creator и StringCreator, который исправляет общий тип:
public interface Creator<T> {
T create();
}
public interface StringCreator extends Creator<String> { }
public class StringCreatorImpl implements StringCreator {
public String create() { return new String(); }
}
public class FancyStringCreator implements StringCreator {
public String create() { return new StringBuffer().toString(); }
}
public static void main(String[] args) throws Exception {
Class<?> someClass = Class.forName(args[0]);
Class<? extends StringCreator> creatorClass = someClass.asSubclass(StringCreator.class);
Constructor<? extends StringCreator> creatorCtor = creatorClass.getConstructor((Class<?>[]) null);
Creator<String> creator = creatorCtor.newInstance((Object[]) null);
}
Но, конечно, вы теряете немного гибкости, потому что вы не можете использовать следующий класс создателя:
public class AnotherCreator implements Creator<String> {
public String create() { return ""; }
}
13 ответов
Самым важным является согласованность . Если для этого нет руководств по кодированию, выберите одно и придерживайтесь его. Но, если ваша команда уже имеет стандарт де-факто, не меняйте его!
Тем не менее, я думаю, что наиболее распространенным является
const int* i;
int* const j;
, потому что большинство людей пишут
]const int n;
вместо
int const n;
Примечание: простой способ прочитать указатель const - прочитать декларацию, начинающуюся справа.
const int* i; // pointer to an int that is const
int* const j; // constant pointer to a (non-const) int
int const* aLessPopularWay; // pointer to a const int
Мне нравится использовать следующую форму для объявления «явных констант» . В этом случае само значение является константой, поэтому я ставлю сначала «const» ( то же самое, что и у Бьярне ), чтобы подчеркнуть, что константность должна проявляться во время компиляции и использоваться как таковая для конкретных оптимизаций с помощью компилятор.
const int i = 123;
Для объявления ссылок, которые не будут использоваться для изменения значения, я использую следующую форму, которая подчеркивает тот факт, что идентификатор является «постоянной ссылкой». Указанное значение может быть или не быть константой. [Связанное обсуждение: Вы бы даже использовали «const» для параметров функции, если бы они не были указателями или ссылками? Использование «const» для параметров функции ]
void fn( int const & i );
Для указателей я использую ту же форму, что и для ссылок, по сути по той же причине (хотя термин «постоянный указатель») "кажется немного более двусмысленным, чем" постоянная ссылка ").
void fn( int const * i );
Кроме того, как заметил другой автор, эта форма остается последовательной, когда у вас есть несколько уровней косвенности.
void fn( int const * const * i );
Последний сценарий, где вы объявляете указатель, который является постоянным, довольно редко встречается в моем опыте с C ++. В любом случае, у вас действительно нет выбора здесь. [Этот случай демонстрирует, что наиболее последовательным подходом было бы поставить слово «const» после типа - поскольку для этого конкретного объявления фактически требуется .]
void fn( int * const i );
... если вы не используете typedef.
typedef int * IntPtr;
void fn1( const IntPtr i );
void fn2( IntPtr const i );
И последнее замечание: если вы не работаете в домене низкого уровня, большая часть кода C ++ не должна никогда не объявлять указатель . Следовательно, этот аспект этого обсуждения, вероятно, больше относится к C.
Главная проблема здесь заключается в том, что он считает, что помещать const после int настолько ужасно некрасиво и настолько вредно для читабельности, что его следует запретить в руководстве по стилю
Правда?
Покажите мне программиста, который застревает, когда видит:
int foo() {
}
против
int foo()
{
}
... и я покажу вам программиста, который не ' уделять достаточно внимания деталям.
Ни один профессиональный программист, достойный его соли, не будет иметь проблем с поверхностными различиями в стиле.
РЕДАКТИРОВАТЬ: Это правда, что const int * и int * const не означают одно и то же, но это не главное. Сотрудник OP отметил, что различия в стиле затрудняют понимание кода & amp; поддерживать. С этим утверждением я не согласен.
Я надеюсь, что это объяснение из часто задаваемых вопросов Б. Страуструпа о Style & amp; Техники дадут вам определенный ответ.
Часто задаваемые вопросы Бьярна Страуструпа о стиле и технике C ++
Я лично предпочитаю:
int const* pi;
int* const pi;
Потому что const идентифицирует левый токен, который предназначен для быть постоянным.
И вы определенно сохраняете ту же последовательность при использовании чего-то такого:
int const* const pi;
Вместо того, чтобы писать непоследовательно:
const int* const pi;
И что произойдет, если у вас есть указатель на указатель и Итак:
int const* const* const pi;
Вместо:
const int* const* const pi;
Помещение «const» после объявления типа имеет гораздо больше смысла, как только вы научитесь читать объявления типа C ++ справа налево.
Я собираюсь привязать твоего корова-оркера к 0-на-3 :)
Правилам стоит следовать. Более простые правила лучше. Const идет справа от того, что const.
Возьмите это объявление:
int основной (int const argc , char const * const * const argv ) ...
Лично я (и это личное предпочтение) мне проще всего читать объявления типов справа налево. Особенно, когда вы начинаете добавлять отсылки к вам.
std::string const& name = plop; // reference to const string.
const std::string& flame =plop; // reference to string const;
// That works better if you are German I suppose :-)
Люди обычно используют const int * blah , потому что он хорошо читается на английском языке. Я бы не стал недооценивать полезность этого.
Я считаю, что вариант int * const blah достаточно редок, поэтому обычно нецелесообразно делать более общее определение в обратном порядке. В общем, я не поклонник чего-либо, что хотя бы слегка затемняет код в общем случае, хотя может дать некоторую номинальную выгоду в исключительном случае.
См. Также «if (1 == a)». Некоторым людям действительно нравится писать код, который не воспринимается как английский. Я не из тех людей.
На самом деле, правила, лежащие в основе const, просты. Посмотрите налево, затем направо. Настолько просто, что я бы не подумал, что в руководстве по стилю это заслуживает особого внимания.
Хотя нет значимой разницы между const int и int const (и я видел оба стиля в использовании), разница есть между const int * и int * const .
В первом случае у вас есть указатель на const int. Вы можете изменить указатель, но не можете изменить значение, на которое он указывает. Во втором у вас есть указатель const на int. Вы не можете изменить указатель (надеюсь, он инициализирован по своему вкусу), но вы можете изменить значение указанного int.
Правильное сравнение - с const int * и int const * , которые оба являются указателями на const int
Помните, что * не обязательно работает так, как вам хотелось бы. Объявление int x, y;
Я был на конференции, где Бьярн Страуструп проводил презентацию, и он использовал что-то вроде const int * i; Кто-то спросил его, почему этот стиль, и он ответил (перефразируя): «Людям нравится сначала видеть константу, когда что-то постоянно».
Существует класс примеров, в которых размещение константы справа от типа также помогает избежать путаницы.
Если у вас есть тип указателя в typedef, то изменить его невозможно. постоянство типа от до :
typedef int * PINT;
const PINT pi;
'pi' по-прежнему имеет тип 'int * const', и это то же самое, где бы вы ни написали 'const'.
I agree with both of you. You should put the const after the type. I also find looking at it an abomination that must be destroyed. But my recent foray into the wonders of const value parameters has made me understand why putting the const second makes sense.
int *
int const *
int * const
int const * const
Just looking at that has the hairs on my neck standing. I'm sure it would confuse my co-workers.
EDIT: I was just wondering about using this in classes:
class Foo {
Bar* const bar;
Foo(const Foo&) = delete; // would cause too many headaches
public:
Foo() : bar(new Bar) {}
~Foo() { delete bar; }
};
bar in this example is functionally equivalent to Bar& but it is on the heap and can be deleted. For the lifetime of each Foo, there will be a single Bar associated with it.
Если бы только переменные и указатели на них могли быть const или нет, это, вероятно, не имело бы такого большого значения.Но учтите:
class MyClass
{
public:
int foo() const;
};
Ни в коем случае const не может быть записано где-либо еще, кроме завершающего функции, на которую он ссылается.
Чем короче руководство по стилю, тем больше вероятность, что разработчики ему будут следовать. И самое короткое из возможных правил, а также правило only , которое даст вам согласованность , это:
Ключевое слово const всегда отстает что бы там ни было.
Итак, я бы сказал 0: 3 для вашего коллеги здесь.
Относительно вашей «основной проблемы»: Ради руководства по стилю, не имеет значения , «препятствует» или «запрещает» руководство то, против чего оно выступает. Это социальный вопрос, политика. Само руководство по стилю должно быть максимально четким и коротким. Длинные руководства по стилю просто игнорируются всеми (кроме руководства, ищущего виноватых), поэтому просто напишите «делать» или «не делать» и укажите, что вы делаете с нарушениями руководства в другом месте (например, в политике компании. о том, как проводятся экспертные оценки).