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

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


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

Подсказка:
h - указатель на процедуру без типа: procedure(void *arg), где "procedure" - может быть любым именем.

Спасибо огромное

На что, простите?

процедуру/функцию без возваращаемого типа = просто на процедуру

может будет полезно - http://unixwiz.net/techtips/reading-cdecl.html

Цитата(GetSmart @ Oct 15 2009, 15:52)

процедуру/функцию без возваращаемого типа = просто на процедуру

В языке Си нет понятия "процедура".

Чем понятие "процедура" разительно отличается от понятия "функция" ?

Не знал

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

Поклоники кошерных функций считают, что функции, в отличие от процедур, еще не должны получать параметры по ссылкам.

К чему этот смайл?

Мы же вроде не о Паскале говорим.

Да все знают. И ответ топикстартеру был понятен.
Просто придрались к слову, потому и смайл

P.S. Sorry, не сдержался.

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

Речь идёт конкретно про Си. Реквестирую цитату из стандарта Си, где определяется "процедура".

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

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

Только про ответ- на нормальном языке это должно быть так:
h - указатель на функцию без возвращаемого значения с одним аргументом в виде (void *arg)
т.е.

пардон за занудство, но иногда это уместно.

Дайте _Pashе медаль. И ещё одну, за занудство

Вы же умный человек. Зачем за слова цепляться. В Си процедура и функция - едино, как любовь и Родина Русский язык богат на синонимы. А слышали вы когда-нибудь о термине "процедурный тип программирования"? Да стандарт написан на английском языке и что... Они, когда о грудном ребёнке говорят, используют It (оно) - нас же коробит. Нужна адаптация. Я вот недавно в книжном магазине был, предварительно прочитав книгу Роберта Хайнлайна "Чужак в чужой стране", так теперь на полках стоят и "Чужак в чужой земле" и "Чужак в стране чужой" - так я не могу их читать после оригинала. Тут есть о чём поспорить, пообсуждать, остальное - "пыль для моряка"...
Ага

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

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


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

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

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

Зри в корень! © К.Прутков

P.S. Когда нечего сказать - спроси: "а где в стандарте это прописано?" - дискуссия гарантирована

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

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


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


Класс! Да будет вам известно, что в языке SmallTalk абсолютно все основано на ОПП, и там любая функция объекта является виртуальной, т.е. является методом. В то время как в языке C++, виртуальными являются только функции, специально объявленные с квалификатором virtual, и они - да, являются методами, но все остальные нестатические функции-члены классов являются просто обыкновенными функциями-членами и никакими методами не являются. И называть их методами - есть проявление безграмотности.

Можете сами сделать вывод о связи терминологии с профессионализмом.



Вот именно!


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

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

Терминология идет, как уже было сказано, с ООП языков, но там проще в этом смысле - там все функции объектов являются методами. Что касается С++, то про упомянутое, в частности, есть фраза Б.Страуструпа (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).

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

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

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



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

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

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


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

Сэкономили

Поддерживаю тезис ARV, что профессионал видит в первую очередь суть.

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

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

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

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

Не передёргивайте. Я не назвал по-другому. Я дифференцировал термин. Я не процессор назвал микросхемой, а микросхему - процессором, в случае когда в стандарте есть только один термин "микросхема".

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


А где на асме процедуры? Что там понимается под процедурой? Сначала определите термины четко, потом на их основе излагайте информацию. На асме такого рода терминов вообще мало. То, что вы подразумеваете под "процедурой" на асме называется, как правило, "подпрограммой" (subroutine). Это куда более уместный термин. И более устоявшийся. Надо полагать, по этой самой причине.


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


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

Пример. Слово "лук". Это что? Лук репчатый? Или лук для стрельбы? Поэтому всегда важен контекст, на основе которого и происходит выборка правильного образа - в кулинарной книге образ будет один, а в книжке про Робина Гуда - второй.

В нашем случае, если слово "процедура" употребляется в контексте языка Паскаль, то у меня оное слово вызывает образ вызываемого исполняемого кода, не возвращающего значения. В контексте языка С/C++ слово "процедура" вызывает совсем иной образ - например, "процедура обмена сигнатурами..." или "процедура подготовки данных...", т.е. это обозначение алгоритмической единицы, но не языка, а непосредственно алгоритма программы.

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

У вас процесс восприятия происходит точно так же, как у всех:



Т.е. как раз и ищется соответствие слова и образа. Только вот контекст в некоторых случаях выбран неверно - при рассмотрении вопросов программирования на С, контекст восприятия у вас паскальный.

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

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

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

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

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

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

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

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




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

Это скорее на совести авторов терминологии языка Си, т.к. именно они расширили термин "функция" (в корыстных целях, кстати) на ситуацию когда она может не возвращать результат. В общем смысле этого понятия результат обязателен.


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

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


Какие нафик заборы? Речь идёт о Майкрософте! "Quick C - Компилятор с языка СИ фирмы Микрософт"


А оригиналы пишут Боги Если Бог сказал - функция, значит хоть убейся, но это будет функция, даже если это процедура

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

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



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

Сформулируйте тогда альтернативное понятие (свободное от навязанных си и паскалем). Правда,оч интересно.
ЗЫ: медаль съел(обе), спасибо, невкусно

Заберите у _Pashи медаль Он накосячил в вызове функции/процедуры по указателю. Надо так:




Да нормально всё определено в Паскале. Вирту - респект. Мне такая дифференциация очень помогает в работе. Но навязывать что-то другим не собираюсь. В общении с особо озабоченными сишниками буду стараться говорить на их "языке". Не факт что получится Но в моих мозгах понятия процедуры и функции никогда не сольются в одно общее понятие функции.

Решил таки копнуть поглубже Поискал по имеющимся книжкам.

1. Bruce Eckel - "Thinking in C++", Глава 10, задание 28:

- статический, следовательно - невиртуальный, но метод.
Там же, Глава 16:

- при этом из приведённого исходника видно, что ни begin() ни end() - не виртуальные.

2. Dale N. - "C++ plus data structures (3rd edition) (2003)", глоссарий:

- ни слова о виртуальности.

3. "Design Patterns":

- тоже никакого обособления виртуальных методов.

4. Ален Голуб - "Верёвка достаточной длины":

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

То есть, похоже, что разделение "виртуальные функции-члены = методы, невиртуальные = просто функции-члены" - не является общепринятой терминологией. Хотя идея неплохая

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



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


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

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

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

Да!

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


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



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



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

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



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

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


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

Например:



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


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



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


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


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


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


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


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


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

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

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

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

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

ЗЫ. И незачем в рот смотреть авторам терминологии. В их терминологии не факт, что всё гладко. Именно поэтому:

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

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

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

На этом свое участие в данной дискуссии прекращаю. Всего вам хорошего. И всем спасибо.

Путаница в словах так же является признаком того, что человек мыслит не словами, а образами. И уже вспешке "конвертируя" их в слова не всегда тратит время на их 100% совпадение. В то же время этот человек может замечать гораздо более тонкие нюансы относительно человека, мыслящего словами. Поэтому не факт, что этот стереотип верный:

Хотя, если считать обратным == "Кто ясно мыслит, не всегда ясно излагает" => то я не спорю

Долой стереотипы!

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


Вам тоже спасибо. Приятно пообщаться с умным человеком