"get () const" против "getAsConst () const"

Хотя, похоже, ваш вопрос касается только одного метода, я был бы рад внести свой вклад в стиль. Лично я по стилю предпочитаю первое. Большинство IDE покажут вам сигнатуру типа функций.

C++ должен отлично справляться с методом A почти во всех ситуациях. Я всегда им пользуюсь, и у меня никогда не было проблем.

Метод Б, на мой взгляд, является случаем нарушения OnceAndOnlyOnce. И теперь вам нужно выяснить, имеете ли вы дело с константной ссылкой для написания кода, который компилируется в первый раз.

Я предполагаю, что это стилистическая вещь - технически они оба работают, но MethodA заставляет компилятор работать немного сложнее. Для меня это хорошо.

Я бы предпочел первое. В коде лучше выглядит, когда две вещи, которые, по сути, делают одно и то же, выглядят одинаково. Кроме того, у вас редко бывает объект, не являющийся константой, но вы хотите вызвать метод const, так что это не является большой проблемой (и в худшем случае вам понадобится только const_cast <>).

Лично я предпочитаю первый метод, потому что он обеспечивает более согласованный интерфейс. Кроме того, для меня getAsConst () звучит так же глупо, как и getAsInt ().

С другой стороны, вам действительно стоит дважды подумать, прежде чем возвращать неконстантную ссылку или неконстантный указатель на член данных вашего класса. Это приглашение к использованию внутренней работы вашего класса, которая в идеале должна быть скрыта. Другими словами, это нарушает инкапсуляцию. Я бы использовал get () const и set () и возвращал неконстантную ссылку, только если нет другого пути или когда это действительно имеет смысл, например, чтобы предоставить доступ для чтения / записи к элементу массива или матрица.

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

Ну, во-первых, getAsConst должен будет вызываться, когда указатель this является константным, а не когда вы хотите получить константный объект. Так что, наряду с любыми другими проблемами, он назван неправильно. (Вы все еще можете называть это, когда 'this' не является константой, но это ни здесь, ни там.)

Игнорируя это, getAsConst ничего не приносит и ложится чрезмерным бременем на разработчика, использующего интерфейс. Вместо того, чтобы просто вызвать get и знать, что он получает то, что ему нужно, теперь он должен выяснить, использует ли он в настоящее время переменную const, и должен ли новый объект, который он захватывает, быть const. А позже, если оба объекта станут неконстантными из-за некоторого рефакторинга, ему придется отключить свой вызов.

Учитывая прецедент стиля, установленный стандартной библиотекой (то есть begin () и begin () const, чтобы назвать только один пример), должно быть очевидно, что метод A является правильным выбором. Я сомневаюсь в здравомыслии человека, который выбирает метод Б.

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

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

Поскольку вы скрываете имена классов, эта пища для размышлений о стиле может применяться, а может и не применяться:

Имеет ли смысл указывать этим двум объектам, MethodA и MethodB, «get» или «getAsConst»? Вы бы отправили «get» или «getAsConst» в виде сообщений любому объекту?

На мой взгляд, как отправитель сообщения / инициатора метода ты получает значение; поэтому в ответ на это сообщение "get" вы отправляете какое-то сообщение в MethodA / MethodB, результатом которого является значение, которое вам нужно получить.

Пример: если вызывающий MethodA - это, скажем, сервис в SOA, а MethodA - репозиторий, то внутри get_A () сервиса вызовите MethodA.find_A_by_criteria (...).

Итак, первый стиль обычно предпочтительнее.

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

В моем конкретном примере у нас есть getTessellation и getMutableTessellation. Он реализован с помощью указателя копирования при записи. По соображениям производительности мы хотим, чтобы всегда использовалась версия const, поэтому мы делаем имя короче и делаем другое имя, чтобы люди случайно не создали копию, когда они все равно не собирались писать.

Главный технологический недостаток MethodB, который я видел, заключается в том, что при применении к нему универсального кода мы должны удвоить код для обработки как константной, так и неконстантной версии. Например:

Скажем, T - это упорядочиваемый объект (то есть мы можем сравнивать с объектами типа T с помощью operator <), и допустим, мы хотим найти максимум между двумя MethodA (соответственно, двумя MethodB).

Для MethodA все, что нам нужно кодировать, это:

template <typename T>
T & getMax(T & p_oLeft, T & p_oRight)
{
   if (p_oLeft.get() > p_oRight.get())
   {
      return p_oLeft ;
   }
   else
   {
      return p_oRight ;
   }
}

Этот код будет работать как с константными объектами, так и с неконстантными объектами типа T:

// Ok
const MethodA oA_C0(), oA_C1() ;
const MethodA & oA_CResult = getMax(oA_C0, oA_C1) ;

// Ok again
MethodA oA_0(), oA_1() ;
MethodA & oA_Result = getMax(oA_0, oA_1) ;

Проблема возникает, когда мы хотим применить этот простой код к чему-то в соответствии с соглашением MethodB:

// NOT Ok
const MethodB oB_C0(), oB_C1() ;
const MethodB & oB_CResult = getMax(oB_C0, oB_C1) ; // Won't compile

// Ok
MethodA oB_0(), oB_1() ;
MethodA & oB_Result = getMax(oB_0, oB_1) ;

Чтобы MethodB работал как с константной, так и с неконстантной версией, мы оба должны использовать уже определенный getMax, но добавить к нему следующую версию getMax:

template <typename T>
const T & getMax(const T & p_oLeft, const T & p_oRight)
{
   if (p_oLeft.getAsConst() > p_oRight.getAsConst())
   {
      return p_oLeft ;
   }
   else
   {
      return p_oRight ;
   }
}

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

Конечно, при достаточной паранойе вторая функция-шаблон должна была называться getMaxAsConst ... И, таким образом, проблема распространялась бы на весь код ...

:-п