[GetSmart 0]

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

Введите в гугле "процедуры в языке си" и зачитайтесь :) Особенно первой ссылкой

http://www.codenet.ru/progr/cpp/qc/

Quick C - Компилятор с языка СИ фирмы Микрософт

Вызов процедур на языке Ассемблер из языка СИ. С.3. Вызов языка СИ из языка Ассемблер. С.4. Сегментная модель фирмы Microsoft. ...

www.codenet.ru/progr/cpp/qc/ - Сохранено в кэше - Похожие

Изменено 16 октября, 2009 пользователем GetSmart

[dxp 67]

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

 

 

Введите в гугле "процедуры в языке си" и зачитайтесь :) Особенно первой ссылкой

http://www.codenet.ru/progr/cpp/qc/

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

[GetSmart 0]

Речь не о ступоре, а о некорректном использовании терминов, что вносит просто путаницу и затрудняет восприятие/общение.

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

 

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

 

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

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

 

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

 

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

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

 

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

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

Изменено 16 октября, 2009 пользователем GetSmart

[AHTOXA 18]

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

 

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

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

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

 

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

 

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

 

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

[_Pasha 0]

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

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

ЗЫ: медаль съел(обе), спасибо, невкусно :)

[GetSmart 0]

void somefunc(void *param);// объявили
.................................................................
sys_timeout_handler h;
int main(void)
{
h = &somefunc;
........BUBUBU.....
h(NULL);
}

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

 

int main(void)
{
h = &somefunc;
........BUBUBU.....
(*h)(NULL);
}

 

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

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

Изменено 16 октября, 2009 пользователем GetSmart

[AHTOXA 18]

Всё равно не вижу тождества "метод == виртуальный" :)

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

 

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

Write static methods to print out the arrays.

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

Там же, Глава 16:

container class has the begin( ) and end( ) methods to produce these iterators.

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

 

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

method: a function declared as member of class object

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

 

3. "Design Patterns":

Object-oriented programs are made up of objects. An object packages both data and the procedures that operate on that data. The procedures are typically called methods or operations.

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

 

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

97. Наследование - это процесс добавления полей данных и методов-членов.

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

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

 

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

[dxp 67]

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

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

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

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

 

 

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

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

 

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

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

 

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

 

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

[AHTOXA 18]

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

Да!

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

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

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

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

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

 

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

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

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

[dxp 67]

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

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

 

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

Виртуальные методы - это масло масленное. :) Если функция гарантировано не переопределяется, то это не метод для потомка, это просто унаследованный код. Методом оно станет только тогда, когда потомок имеет возможность реализовать эту функцию своим способом - т.е. у него свой способ = метод, отличающийся от спо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 18]

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

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

[GetSmart 0]

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

 

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

 

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

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

Изменено 18 октября, 2009 пользователем GetSmart

[dxp 67]

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

 

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

 

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

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

 

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

 

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

 

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

[GetSmart 0]

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

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

"Кто ясно мыслит, ясно излагает" (с). Обратное тоже верно.

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

 

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

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

 

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

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

 

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

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

Изменено 18 октября, 2009 пользователем GetSmart