Растолкуйте по шаблону С++ Опции

[VladislavS]

Помогите, плиз, устранить пробел в знаниях. Что значит второе определение Set() в этом шаблоне?

Код

template<class Regs>
class PortImplementation
{
  public:
    static void Set(uint16_t value)
    {
      Regs()->BSRR = value;
    }

    template<uint16_t value>
    static void Set()         //<--- ???
    {
      Regs()->BSRR = value;
    }
};

[dxp]

Функция, объявленная внутри класса и являющаяся нестатической == функция-член.
Виртуальная функция-член == метод.

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

[Kabdim]

Виртуальная функция-член == метод.

А вы сможете подтвердить это пунктом стандарта? Я вот сейчас поискал из любопытства - вдруг позабывал всё и не нашел.

[dxp]

А вы сможете подтвердить это пунктом стандарта? Я вот сейчас поискал из любопытства - вдруг позабывал всё и не нашел.

Я ждал этого вопроса.

В стандарте С++ вообще нет термина "метод". Но зато этот термин без разбора применяют как псевдоним термина "функция-член" - очевидно потому, что это короче. Между тем, термин "метод" взят из объектно-ориентированных языков, где все объекты существуют в иерархиях и все их функции-члены по сути являются виртуальными, поэтому и являются методами. Смысл этого очень простой: когда у вас иерархия объектов, то при наследовании классы-потомки имеют "по наследству" весь набор функций-членов предков, но при этом в потоках сами эти функции могут быть перекрыты - т.е. заменены на свои, классический пример - иерархия классов геометрических фигур:

Код

Figure
    Circle
    Triangle
    Rectangle

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

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

В реальности ровно эта задача встаёт при реализации GUI - там все виджеты сами отрисовывают себя своим способом - методом.

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

Теперь когда мы переходим к С++, который не является чистым ОО языком, а является гибридным языком, поддерживающим разные парадигмы программирования: процедурную, объектную, объектно-ориентированную, то очевидно, что далеко не все функции-члены классов являются именно методами, а только те, которые несут смысл, представленный выше. А это относится только к ОО части С++, т.е. к иерархиям наследования и их виртуальным функциям-членам, которые, безусловно, являются методами.

В книге автора языка Б. Страуструпа есть фраза: "Иногда виртуальные функции-члены называют методами".

Относиться к ситуации можно по-разному, и много людей просто кладут на аргументацию и не дают себе труда ни разобраться, ни следовать этому - для них "метод" просто удобнее, потому что короче. Кто-то просто не в курсе дела, а в книжках и на форумах пишут "метод", вот они и повторяют. Но я считаю, что терминологическая точность должна быть, иначе начинает теряться просто смысл терминологии, поэтому лучше не лениться и называть вещи правильно.

[Kabdim]

чтобы немного облагородить ругательство "функция-член".

Да кмк здесь слово метод более употребительно чем там, но и там оно тоже используется.

Вопрос на самом деле неоднозначный. Вот к примеру есть PPP Style Guide, в котором Страуструп пишет на 9 странице:

Not every member function (”method”) should be virtual and by default they are not

Из-за чего так? Кмк потому что методы вошли в общепринятую терминологию позже плюсов. К тому же вошли в двух разных школах. В ораклово-явовской метод=вирутальная функция член, в майкрософто-решеточной (и дельфевской из которой решетка переняла многое) метод просто функция в классе. Поэтому прошу не утверждать что есть единая верная интерпретация. Вообще в оригинале абстрактного ОО (Smalltalk) метод диспетчеризуется по имени, о чем (и вообще о философии ОО применительно к плюсам) Страуструп рассуждает в What is ‘‘Object-Oriented Programming’’ - рекомендую прочитать.

[dxp]

Да кмк здесь слово метод более употребительно чем там, но и там оно тоже используется.

Я вижу, вам тоже оно нравится (более коротко и/или привыкли).

Из-за чего так? Кмк потому что методы вошли в общепринятую терминологию позже плюсов.

"Метод" (как и ООП) появился куда раньше плюсов. Обратите внимание, он говорит про Java и взял в кавычки, подчёркивая, что в плюсах далеко не все функции-члены являются методами.

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

Я ничего не утверждаю. Ну, разве что то, что термина "метод" в С++ нет вообще. Есть функция, функция-член, статическая функция-член, виртуальная функция-член. На последнюю можно отмапить термин "метод", переходя на ОО терминологию. Но тащить её дальше и обобщать - это как-то слишком.

Вообще в оригинале абстрактного ОО (Smalltalk) метод диспетчеризуется по имени, о чем (и вообще о философии ОО применительно к плюсам) Страуструп рассуждает в What is ‘‘Object-Oriented Programming’’ - рекомендую прочитать.

Вот если вы пройдёте по вхождениям словам "method", то убедитесь, что Страуструп очень аккуратно использует терминологию, употребляя этот термин именно как синоним виртуальной функции-члена, например (стр. 20):

This idea captures only part of the expressive
power of inheritance, but it is strongly encouraged by languages where every member function is virtual
(or a method).