Непонятный typedef Опции

[Harvester]

Столкнулся вот с таким переопределением типа:

Код

typedef void (* sys_timeout_handler)(void *arg);

(Это из стека lwIP)
И никак не могу понять, что же из себя представляет переменная h, объявленная как

Код

sys_timeout_handler h;

Буду признателен за подсказку.

[GetSmart]

Процедуры и функции и прочее - это алгоритмические еденицы. Они есть везде, где есть алгоритмы.

Видимо проблема растёт из "нового" образования в школах/вузах. Раньше, когда в обязательном порядке изучали Паскаль ни у кого бы не возникло отторжение понятия процедуры.

[dxp]

Процедуры и функции и прочее - это алгоритмические еденицы. Они есть везде, где есть алгоритмы.

Да? А вот в языке Verilog, например, есть function и task, процедуров не завезли. Как быть?

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

Видимо проблема растёт из "нового" образования в школах/вузах. Раньше, когда в обязательном порядке изучали Паскаль ни у кого бы не возникло отторжение понятия процедуры.

Проблема растет из недостаточного знания матчасти и/или небрежного отношения мелочам. И это зря. "Профессионал отличается от любителя отработкой мелочей" (с).

[AHTOXA]

В нем же функции-члены классов - это функции члены классов, а не методы, как их многие называют. Методы в С++ - это виртуальные функции.

Первый раз слышу о таком разделении. Где такое прописано?

[dxp]

Первый раз слышу о таком разделении. Где такое прописано?

Терминология идет, как уже было сказано, с ООП языков, но там проще в этом смысле - там все функции объектов являются методами. Что касается С++, то про упомянутое, в частности, есть фраза Б.Страуструпа (The C++ Programming Language, Third Edition by Bjarne Stroustrup. Copyright ©1997 by AT&T.
Published by Addison Wesley Longman, Inc. ISBN 0-201-88954-4., 12.2.6 Virtual Functions):

To allow a virtual function declaration to act as an interface to functions defined in derived
classes, the argument types specified for a function in a derived class cannot differ from the argu-
ment types declared in the base, and only very slight changes are allowed for the return type
(§15.6.2). A virtual member function is sometimes called a method.
A virtual function must be defined for the class in which it is first declared (unless it is declared
to be a pure virtual function; see §12.3).

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

[AHTOXA]

Ясно, спасибо. Замечу всё же, что "иногда называют методом" - это весьма нестрого, и не тянет на строгое терминологическое определение

-----
Я тут ещё вот что подумал...

Да, и по смыслу метод - это переопределенное (т.е. измененное в наследниках) действие объекта

Это ведь чисто умозрительно. Если уж речь идёт о точной терминологии, то надо оперировать какими-то более весомыми определениями, чем "по смыслу". Я, например, не нашёл указаний, что метод должен быть обязательно переопределяем.
Вот например, из википедии:

Метод в объектно-ориентированном программировании - это функция, принадлежащая какому-то классу или объекту.

Никаких намёков на переопределяемость.

[dxp]

Ясно, спасибо. Замечу всё же, что "иногда называют методом" - это весьма нестрого, и не тянет на строгое терминологическое определение

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

Я тут ещё вот что подумал...

Это ведь чисто умозрительно. Если уж речь идёт о точной терминологии, то надо оперировать какими-то более весомыми определениями, чем "по смыслу". Я, например, не нашёл указаний, что метод должен быть обязательно переопределяем.
Вот например, из википедии:

Никаких намёков на переопределяемость.

Ключевое словосочетание: "в объектно-ориентированном программировании". Т.е. задан контекст. В ООП все функции являются переопределяемыми (виртуальными), поэтому нет смысла это специально выделять. А С++ - язык гибридный, в нем сочетаются несколько парадигм программирования, в нем есть и обычные функции, и виртуальные, кои являются методами по ООП терминологии. А путаница возникает оттого, что некоторые люди, не задумываясь, переносят терминологию из ООП на другие парадигмы - в частности, в С++ - на объектную (классы, объекты классов).

[AHTOXA]

Ключевое словосочетание: "в объектно-ориентированном программировании". Т.е. задан контекст.

Хорошо, почти убедил Осталось развеять мои сомнения только вот в этом:

В ООП все функции являются переопределяемыми (виртуальными)

Откуда это следует?

ЗЫ. Я не спорю, я действительно хочу разобраться. Потому что у меня слово "метод" совершенно не ассоциируется с виртуальностью.

[dxp]

Откуда это следует?

А что по-твоему ООП? Чем объектно-ориентированный подход отличается от объектного?

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

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

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

Т.е. ООП - это очень эффективный способ управления множеством объектов, связанных между собой "родственными связями", когда известно, что можно делать, но неизвестно в общем случае как (это "как" в каждом случае свое). И по терминологии ООП это что обзывается термином "метод". Другими словами, у каждого объекта есть одинаковое по смыслу действие, но способ его реализации в каждом случае разный. Способ == метод. Отсюда и происхождение этого термина.

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

В чистых же ООП языках все объекты являются связанными, в них все функции-члены реализуются как переопределяемые, т.е. являются как раз методами реализации одних и тех же (по целевому смыслу) действий.

Введите в гугле "процедуры в языке си" и зачитайтесь Особенно первой ссылкой
http://www.codenet.ru/progr/cpp/qc/

Это лишь доказывает, что вы не один попали под влияние Паскаля. К тому же, надо делать скидку, что переводы тоже делают люди. Не случайно А.С.Пушкин называл переводчиков "подставными лошадьми истории". Ну, и в конце концов, мало ли что пишут на заборах. Мы тут серьезно разговариваем, т.ч. давайте апеллировать к серьезным источникам, коими являются Стандарт языка и его автор[ы].

[AHTOXA]

Т.е. ООП - это очень эффективный способ управления множеством объектов, связанных между собой "родственными связями", когда известно, что можно делать, но неизвестно в общем случае как (это "как" в каждом случае свое). И по терминологии ООП это что обзывается термином "метод". Другими словами, у каждого объекта есть одинаковое по смыслу действие, но способ его реализации в каждом случае разный. Способ == метод. Отсюда и происхождение этого термина.

Всё равно не вижу тождества "метод == виртуальный" В той же графике, метод move(x, y), например, вполне может быть одинаков для всех фигур, и состоять из

Код

{
    erase();
    set_pos(x, y);
    draw();
}

, и потому ему совершенно необязательно быть виртуальным.

То есть, (имхо), метод = действие объекта, виртуальный = переопределяемое действие объекта. И эти вещи более или менее ортогональны. Поэтому я всё же склоняюсь к мысли, что название "метод" - это просто краткий способ назвать функцию класса. Ещё более в этом мнении меня утверждает существование термина "Виртуальный метод". Раз есть "виртуальный", то, наверное, должен быть и просто метод?

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

А, я наконец понял, откуда идёт эта аналогия. Метод = метод (вариант) реализации? Понятно. Но всё же не соглашусь. Метод - это функция объекта, независимо от того, есть у объекта родственные связи или нет. Единственный вариант(метод) реализации - тоже вариант (метод) )

[dxp]

Всё равно не вижу тождества "метод == виртуальный" В той же графике, метод move(x, y), например, вполне может быть одинаков для всех фигур, и состоять из

Код

{
    erase();
    set_pos(x, y);
    draw();
}

, и потому ему совершенно необязательно быть виртуальным.

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

То есть, (имхо), метод = действие объекта, виртуальный = переопределяемое действие объекта. И эти вещи более или менее ортогональны. Поэтому я всё же склоняюсь к мысли, что название "метод" - это просто краткий способ назвать функцию класса. Ещё более в этом мнении меня утверждает существование термина "Виртуальный метод". Раз есть "виртуальный", то, наверное, должен быть и просто метод?

Скажи, какой смысл называть обычную функцию-член, никак не связанную по смыслу с иерархией наследованных классов, методом? Почему метод? В чем метод? Метод чего? В ООП - понятно. Это метод реализации. И если не это, то что?

А, я наконец понял, откуда идёт эта аналогия. Метод = метод (вариант) реализации? Понятно. Но всё же не соглашусь. Метод - это функция объекта, независимо от того, есть у объекта родственные связи или нет. Единственный вариант(метод) реализации - тоже вариант (метод) )

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

Что касается ссылок на книжки, то в том-то и беда, что много людей, которые даже давно пользуются многими средствами С++ (в том числе и ООП), оказываются не знакомыми с нюансами обсуждаемой терминологии. Я и сам не так давно понял настоящую суть этого термина, тоже всю жизнь считал, что это более короткое название "функции-члена". Когда увидел у Страуструпа деление, впервые задумался, почему так. Но не допер, а окружение тоже не смогло внятно объяснить. Впоследствии этот вопрос всплывал только когда приходилось иметь дело с ООП, и в какой-то момент, плотно поварившись в этих иерархиях, наступило осознание, почему "метод". И почему обычные функции-члены - не методы.

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

[AHTOXA]

Если он одинаков у неких разных объектов, то просто это означает, что некоторые производные классы используют родительский метод.

Да!

Но никто и ничто не мешает какому-нибудь из производных переопределить свой способ реализации - и него будет уже свой метод выполнить действие "move".

Если метод не объявлен виртуальным, то у них ничего не выйдет
Давай я так скажу - виртуальные методы - те, которые потомки могут изменить, невиртуальные - которые не должны меняться. В этом состоит гибкость наследования. Но и те и другие - методы.
То есть, разработчик базового класса управляет возможностью переопределения методов этого класса.
Скажем, есть метод AddRef() у хитрого указателя. Его переопределять опасно, он должен действовать одинаково для всех потомков. Поэтому он будет невиртуальным. Но ведь он не перестанет от этого быть методом?

Скажи, какой смысл называть обычную функцию-член, никак не связанную по смыслу с иерархией наследованных классов, методом? Почему метод? В чем метод? Метод чего? В ООП - понятно. Это метод реализации. И если не это, то что?

Почему не связанный? Он очень даже связан. Он может вызывать другие виртуальные методы в нужном порядке. Он может обеспечивать общую для всей иерархии логику. Он - метод, просто неизменяемый, инвариантный. И это не метод реализации (это уже немного другая область, и другой термин), а метод класса. В смысле - действе.
Что касается "метода реализации" - это уже другая область, типа паттерны проектирования. Там слово метод имеет другой смысл, и там далеко не всегда применяются виртуальные функции. Бывают шаблоны. Бывают фабрики классов. И многое другое

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

Мы же с тобой сейчас заняты не изобретением новой терминологии. а выяснением существующей. Той. что применяется сейчас.

Что касается ссылок на книжки, то в том-то и беда, что много людей, которые даже давно пользуются многими средствами С++ (в том числе и ООП), оказываются не знакомыми с нюансами обсуждаемой терминологии.

То есть, все неправы? Книжки вроде очень уважаемые. Я вчера ещё у Александреску нашёл употребление слова метод по отношению к невиртуальной функции.

По-моему, единственное упоминание у Страуструпа (причём очень нечёткое) не тянет на устоявшуюся терминологию.

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

Во-первых, где это чёткое определение? Приведи пожалуйста. А во-вторых, почему это чёткое определение относится только к виртуальным функциям С++? Невиртуальные функции разве не наследуются? Разве они не являются точно таким же механизмом ООП?

[dxp]

Если метод не объявлен виртуальным, то у них ничего не выйдет

Конечно! Потому, что если функция не виртуальная - то это не метод!

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

Виртуальные методы - это масло масленное. Если функция гарантировано не переопределяется, то это не метод для потомка, это просто унаследованный код. Методом оно станет только тогда, когда потомок имеет возможность реализовать эту функцию своим способом - т.е. у него свой способ = метод, отличающийся от споcоба/метода родителя.

Например:

Код

class TSlon
{
public:
    ...
    void set_data(int x);
    virtual void set_request() { if(...) PORT0 ^= ...;}
    ...
};


class TMamont : public TSlon
{
public:
    ...
    int blink_led();
    virtual void set_request() { for(...) { ... } }
    ...
}

Ну, и какие же TSlon::set_data и TMamont::blink_led методы, если у них целевое назначение совершенно разное? Они - просто разнокачественный код. Обычный код, никак не связанный между собой по смыслу. А вот их виртуальные функции set_request - это функции, которые имеют одинаковое целевое назначение (сделать запрос), но способ реализации этого у них совершенно разный. Методы достижения разные. Поэтому они - методы.

То есть, разработчик базового класса управляет возможностью переопределения методов этого класса.
Скажем, есть метод AddRef() у хитрого указателя. Его переопределять опасно, он должен действовать одинаково для всех потомков. Поэтому он будет невиртуальным. Но ведь он не перестанет от этого быть методом?

Перестает. Потому, что тут нету никакого способа/метода. Есть просто статический код, который не меняется во всей иерархии.

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

Вдумайся в смысл слов "метод" и "действие". Чувствуешь разницу? Вот "действие" - адекватное обозначение для термина "функция-член". А "метод" - это всегда по смыслу способ. А не действие.

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

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

То есть, все неправы? Книжки вроде очень уважаемые.

В этом вопросе, к сожалению, да. Программисты, там, может, и сильные, но ООП - это отдельная кухня, там свои правила. И не самая часто применяемая парадигма в С++. Все применяется к месту.

Я вчера ещё у Александреску нашёл употребление слова метод по отношению к невиртуальной функции.

В оригинальном тексте или в переводе?

По-моему, единственное упоминание у Страуструпа (причём очень нечёткое) не тянет на устоявшуюся терминологию.

Устоявшаяся она в ООП. Оттуда и ноги растут. И в контексте С++ мнение Страуструпа вполне перетягивает все остальное.

Во-первых, где это чёткое определение? Приведи пожалуйста. А во-вторых, почему это чёткое определение относится только к виртуальным функциям С++?

Ты сам нарыл его в педивикии. Копать надо в источниках по ОО, а не в просто книжках по С++, где и ООП-то рассматривается весьма поверхностно.

Невиртуальные функции разве не наследуются? Разве они не являются точно таким же механизмом ООП?

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

P.S. Что-то мне думается, что дискуссия на эту тему вряд ли кому-то еще тут интересно. Поэтому, дабы не захламлять форум, предлагаю перенести обсуждение в асю/джаббер. Ты как?

[AHTOXA]

P.S. Что-то мне думается, что дискуссия на эту тему вряд ли кому-то еще тут интересно. Поэтому, дабы не захламлять форум, предлагаю перенести обсуждение в асю/джаббер. Ты как?

Ок Написал в личку.