typedef struct _String
{
size_t iLen;
char* pData;
} String;
String* StringCopy(String* Obj, const String* Str);
String* StringSet(String* Obj, const char* Str);
//....
будущее Delphi ;)
Доброго времени суток!:)
Сейчас появляется много новых технологий от Microsoft'а и т.п....
меня интересует будущее Pascal'а..
как вы считаете, останется ли он?:) или вымрет? :(
Сейчас появляется много новых технологий от Microsoft'а и т.п....
меня интересует будущее Pascal'а..
как вы считаете, останется ли он?:) или вымрет? :(
Цитата: Nixus
Не факт. Не читай глупые статейки.
Возьмем пример. Объект строка с точки зрения ООП и функционального программирования.
и
По вашему вызов
будем медленне чем
?
Возьмем пример. Объект строка с точки зрения ООП и функционального программирования.
Код:
и
Код:
struct String
{
size_t iLen;
char* pData;
String& Copy(const String* Str);
String& Set(const char* Str);
// ...
};
{
size_t iLen;
char* pData;
String& Copy(const String* Str);
String& Set(const char* Str);
// ...
};
По вашему вызов
Код:
String S;
S.Set("123123");
S.Set("123123");
будем медленне чем
Код:
String S;
StringSet(&S, "123123");
StringSet(&S, "123123");
?
Вы товарищ погоричились с фразой "Не читай глупые статейки".
Приведеные примеры вообще бред, естественно скорость ты не потеряешь используя ООП. Да это вообще не ООП! Если возьмешь и пересмотришь свой код ты это увидишь. Ты думаешь что это ООП, поменял слово struct на class.
Скорость теряется именно при использовании наследования. При разработки графики как таковой, каждый такт процессора на счету, по крайней мере раньше так было, до появления многоядерных процессоров. И только по этой причине при разработке игр пишется огромное кольчество ассемблерных процедур. Конечно без С++ тяжело обойтись, поэтому частенько да бы не писать на чистом С исползуют возможности С++, но без наследования, вообщем это факт и спорить тут не приходится.
Цитата: koval
Скорость теряется именно при использовании наследования. При разработки графики как таковой, каждый такт процессора на счету, по крайней мере раньше так было, до появления многоядерных процессоров. И только по этой причине при разработке игр пишется огромное кольчество ассемблерных процедур. Конечно без С++ тяжело обойтись, поэтому частенько да бы не писать на чистом С исползуют возможности С++, но без наследования, вообщем это факт и спорить тут не приходится.
Что факт? С чем спорить не приходится?
Что наследование как-то влияет на скорость?
Ну это же БРЕД !
Причем тут появление многоядерных процессоров?
Огромное количество ассемблерных процедур - тоже бред!
Да и при чем тут они?
Зачем так рьяно что-то утверждать, если не разбираешься в этих вещах?
Ты знаешь, как реализуется наследование (в частности в C++) ? Вижу, что даже не догадываешься.
Странно, что ты ещё и шаблоны не приплел...
ПРОГРАММИСТЫ, Я В ШОКЕ !
P.S. Кстати, расскажи ка, как это "возможности С++, но без наследования" ?
P.P.S Если это всё было в статье написано, то найди мне, плз, эту статейку. Хочу надрать уши её писателю.
Цитата: Green
Знаешь анекдот про блондинку:
Понимаешь к чему я клоню?
На чем базируется твоя "банальная логика"?
Давай подведем итог........
Понимаешь к чему я клоню?
На чем базируется твоя "банальная логика"?
Давай подведем итог........
А я веть действительно обижусь....:mad: Я веть не подвожу оценку вашим постам, логике и эрудиции, и с блондинками не сравниваю.... (Блондинки не обижайтесь, я вас УВАЖАЮ и ЦЕНЮ, как людей, и как специалистов)
ВСЕМ
Давайте не будем плодить темы аля "перемывание костей". Тему то не мы создали....
Цитата: misha_turist
А я веть действительно обижусь....:mad: Я веть не подвожу оценку вашим постам, логике и эрудиции, и с блондинками не сравниваю.... (Блондинки не обижайтесь, я вас УВАЖАЮ и ЦЕНЮ, как людей, и как специалистов)
Твою логику и эрудицию я не трогаю.
А вот посты обсуждать имею полное моральное право.
[quote=Green]
Зачем так рьяно что-то утверждать, если не разбираешься в этих вещах?
Ты знаешь, как реализуется наследование (в частности в C++) ? Вижу, что даже не догадываешься.
Странно, что ты ещё и шаблоны не приплел...
[/quote]
Ну почему же, я отлично разбираюсь в ООП, или я так просто думаю ;)
[quote=Green]
Если это всё было в статье написано, то найди мне, плз, эту статейку. Хочу надрать уши её писателю.
[/quote]
-=Без ответа=-
Выдержка про недостатки ООП из Chambers C. (1992) «The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages» // Stanford University, Ph.D. thesis.
Неэффективность на этапе выполнения. В языках типа Smalltalk сообщения интерпретируются во время выполнения программы путем осуществления поиска их в одной или нескольких таблицах и за счет выбора подходящего метода. Конечно, это медленный процесс. И даже при использовании наилучших методов оптимизации Smalltalk-программы в десять раз медленнее оптимизированных C-программ [Cha92].
В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит лишь к вызову через указатель процедурной переменной. На некоторых машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И поскольку сообщения встречаются в программе гораздо реже других операций, их воздействие на время выполнения влияния практически не оказывает.
Однако, существует другой фактор, который затрагивает время выполнения: это абстракция данных. Абстракция запрещает непосредственный доступ к полям класса и требует, чтобы каждая операция над данными выполнялась через методы. Такая схема приводит к необходимости выполнения процедурного вызова при каждом доступе к данным. Однако, когда абстракция используется только там, где она необходима (т.е. не из одной лишь прихоти), то замедление вполне приемлемое.
Неэффективность в смысле распределения памяти. Динамическое связывание и проверка типа на этапе выполнения требуют по ходу работы информации о типе объекта. Такая информация хранится в дескрипторе типа, и он выделяется один на класс. Каждый объект имеет невидимый указатель на дескриптор типа для своего класса. Таким образом, в объектно-ориентированных программах требуемая дополнительная память выражается в одном указателе для объекта и в одном дескрипторе типа для класса.
Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.
Зачем так рьяно что-то утверждать, если не разбираешься в этих вещах?
Ты знаешь, как реализуется наследование (в частности в C++) ? Вижу, что даже не догадываешься.
Странно, что ты ещё и шаблоны не приплел...
[/quote]
Ну почему же, я отлично разбираюсь в ООП, или я так просто думаю ;)
[quote=Green]
Если это всё было в статье написано, то найди мне, плз, эту статейку. Хочу надрать уши её писателю.
[/quote]
-=Без ответа=-
Выдержка про недостатки ООП из Chambers C. (1992) «The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages» // Stanford University, Ph.D. thesis.
Цитата:
Неэффективность на этапе выполнения. В языках типа Smalltalk сообщения интерпретируются во время выполнения программы путем осуществления поиска их в одной или нескольких таблицах и за счет выбора подходящего метода. Конечно, это медленный процесс. И даже при использовании наилучших методов оптимизации Smalltalk-программы в десять раз медленнее оптимизированных C-программ [Cha92].
В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит лишь к вызову через указатель процедурной переменной. На некоторых машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И поскольку сообщения встречаются в программе гораздо реже других операций, их воздействие на время выполнения влияния практически не оказывает.
Однако, существует другой фактор, который затрагивает время выполнения: это абстракция данных. Абстракция запрещает непосредственный доступ к полям класса и требует, чтобы каждая операция над данными выполнялась через методы. Такая схема приводит к необходимости выполнения процедурного вызова при каждом доступе к данным. Однако, когда абстракция используется только там, где она необходима (т.е. не из одной лишь прихоти), то замедление вполне приемлемое.
Неэффективность в смысле распределения памяти. Динамическое связывание и проверка типа на этапе выполнения требуют по ходу работы информации о типе объекта. Такая информация хранится в дескрипторе типа, и он выделяется один на класс. Каждый объект имеет невидимый указатель на дескриптор типа для своего класса. Таким образом, в объектно-ориентированных программах требуемая дополнительная память выражается в одном указателе для объекта и в одном дескрипторе типа для класса.
Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.
[quote=Green]
P.S. Кстати, расскажи ка, как это "возможности С++, но без наследования" ?
[/quote]
В данном случае я говорил про улучшенный С. Использование в С операторов и некоторых конструкций С++.
[quote=Green]
Огромное количество ассемблерных процедур - тоже бред!
Да и при чем тут они?
[/quote]
Сразу встречный вопрос: повсей видимости с графикой ты никогда не работал, я прав?
Моя оценка ООП(ЭТО МОЕ ЛИЧНОЕ МНЕНИЕ)
-Недостатки:
1. Большое количество кода.
2. Ухудшения читабельности чужого кода(Библиотеки классов).
3. Очень неэффективное использование динамической памяти(создание удаление объектов)
4. Низкая производительность за счет опять того же наследования, виртуальных методов.
5. При разработке больших проектов необходимо очень хорошее IDE, или просто, как в лесу заблудишься, в своих же классах.
-Достоинства:
1. Скорость разработки.
2. Большое количество библиотек классов.
P.S. Сам использую ООП, так что каюсь :D
Цитата: koval
Выдержка про недостатки ООП из Chambers C. (1992) «The Design and Implementation of the SELF Compiler, an Optimizing Compiler for Object-Oriented Programming Languages» // Stanford University, Ph.D. thesis.
Для начала обрати внимание на год написания статьи.
Статья (в приведенной части) весьма спорная. Я с ней не согласен.
А теперь по пунктам:
Цитата:
В гибридных языках типа Oberon-2, Object Pascal и C++ посылка сообщения приводит лишь к вызову через указатель процедурной переменной. На некоторых машинах сообщения выполняются лишь на 10% медленнее, чем обычные процедурные вызовы. И поскольку сообщения встречаются в программе гораздо реже других операций, их воздействие на время выполнения влияния практически не оказывает.
Хм... интересно, что подразумевается под понятиями "посылка сообщения" и "процедурная переменная" ?
Рассмотрим три варианта методов классов в С++:
1) статические - ничем не отличаются от обычных функций, а сл-но работают так же затраты на вызов те же;
2) обычные методы - передается указатель на экземпляр класса (this), в С пришлось бы передавать объект отдельным параметром, а по сему разницы так же нет;
3) виртуальные методы - в С аналогом могут служить callback, в любом случае придется разыменовывать указатель на функцию (может, это и есть "процедурная переменная") или обращаться к записи в виртуальной таблице. Так что то же разницы в затратах на вызов нет.
Почему я несогласен с этой частью цитаты понятно?
Идем дальше.
Цитата:
Однако, существует другой фактор, который затрагивает время выполнения: это абстракция данных. Абстракция запрещает непосредственный доступ к полям класса и требует, чтобы каждая операция над данными выполнялась через методы. Такая схема приводит к необходимости выполнения процедурного вызова при каждом доступе к данным. Однако, когда абстракция используется только там, где она необходима (т.е. не из одной лишь прихоти), то замедление вполне приемлемое.
Делайте гетеры/сетеры инлайновыми и будет вам счастье.
Кстати, большинство оптимизаторов справляются с этой "проблемой" автоматически.
Цитата:
Неэффективность в смысле распределения памяти. Динамическое связывание и проверка типа на этапе выполнения требуют по ходу работы информации о типе объекта. Такая информация хранится в дескрипторе типа, и он выделяется один на класс. Каждый объект имеет невидимый указатель на дескриптор типа для своего класса. Таким образом, в объектно-ориентированных программах требуемая дополнительная память выражается в одном указателе для объекта и в одном дескрипторе типа для класса.
В контексте C++ пункт выглядит по-идиотски.
Не используйте RTTI, где это не надо.
А там, где надо, в любом другом языке вы так же не обойдетесь без доп. памяти, будь это даже C или Assembler.
Цитата:
Излишняя универсальность. Неэффективность может также означать, что программа имеет ненужные возможности. В библиотечном классе часто содержится больше методов, чем это реально необходимо. А поскольку лишние методы не могут быть удалены, то они становятся мертвым грузом. Это не воздействует на время выполнения, но влияет на возрастание размера кода.
Линкер прекрасно разберется и оставит только необходимые методы. Сложности будут лишь с виртуальными методами.
Кроме того никто не заставляет писать мега-классы. Наоборот, рекомендуется реализовывать лишь минимальную функциональность.
Что касается STL и пр. шаблонов, то в конечный код попадут лишь используемые методы. А некоторые оптимизаторы умеют даже вырезать дубликаты разных инстанирований.
Короче, не согласен я ни с единым пунктом статьи, если смотреть в контексте C++.
ООП - это парадигма программирования и она никак напрямую не влияет на оптимальность программы по ресурсоемкости. Влияние есть лишь косвенное, через скорость разработки.
Цитата: koval
В данном случае я говорил про улучшенный С. Использование в С операторов и некоторых конструкций С++.
Хм... все равно, не понял, каких именно операторов и "некоторых конструкций" ?
Цитата: koval
Сразу встречный вопрос: повсей видимости с графикой ты никогда не работал, я прав?
По всей видимости, я работаю в игровой компании (см. профайл) и уж повидал исходников игр и пр. приложений, работающих с графикой.
Цитата: koval
Моя оценка ООП(ЭТО МОЕ ЛИЧНОЕ МНЕНИЕ)
-Недостатки:
1. Большое количество кода.
2. Ухудшения читабельности чужого кода(Библиотеки классов).
3. Очень неэффективное использование динамической памяти(создание удаление объектов)
4. Низкая производительность за счет опять того же наследования, виртуальных методов.
5. При разработке больших проектов необходимо очень хорошее IDE, или просто, как в лесу заблудишься, в своих же классах.
-Достоинства:
1. Скорость разработки.
2. Большое количество библиотек классов.
1. Как раз-таки наоборот. Можешь привести пример? Я могу привести пример обратного. Примеры есть тут же на форуме, далеко ходить не надо.
2. Опять таки наоборот. Извини, но ты с каким-то неправильным применгением ООП знаком. Можешь привести пример?
3. А это тут при чем? Какая связь между ООП и памятью? Памятью заведует менеджер памяти, но никак не ООП.
4. Как уже говорил : наследование здесь ни каким боком. Виртуальные методы, как уже говорил, аналог callback-ов. И там и там надо разыменовывать указатель.
5. Это вообще не аргумент, т.к. надо просто "уметь их готовить". А в скоплении функций ты не путаешься? А в чем разница?
Достоинство 2: непонятное какое-то, а библиотек для C, значит, не существует. Или их очень-очень мало?
[quote=Green]
Статья (в приведенной части) весьма спорная. Я я ней не согласен.
[/quote]
Это не статья, а кусок главы из книги.
3. А это тут при чем? Какая связь между ООП и памятью? Памятью заведует менеджер памяти, но никак не ООП.
Достоинство 2: непонятное какое-то, а библиотек для C, значит, не существует. Или их очень-очень мало?
Статья (в приведенной части) весьма спорная. Я я ней не согласен.
[/quote]
Это не статья, а кусок главы из книги.
Цитата:
3. А это тут при чем? Какая связь между ООП и памятью? Памятью заведует менеджер памяти, но никак не ООП.
Очень простая. При частом создании и удалении объектов, плохая фрагментация кучи.(Как ты все понимаешь буквально, и цепляешься к каждому слову)
[quote=Green]
1. Как раз-таки наоборот. Можешь привести пример?
2. Опять таки наоборот. Извини, но ты с каким-то неправильным применгением ООП знаком. Можешь привести пример?
[/quote]
А что ты ожидаешь в качестве примера?
[quote=Green]
1) статические - ничем не отличаются от обычных функций, а сл-но работают так же затраты на вызов те же;
2) обычные методы - передается указатель на экземпляр класса (this), в С пришлось бы передавать объект отдельным параметром, а по сему разницы так же нет;
3) виртуальные методы - в С аналогом могут служить callback, в любом случае придется разыменовывать указатель на функцию (может, это и есть "процедурная переменная") или обращаться к записи в виртуальной таблице. Так что то же разницы в затратах на вызов нет.
Почему я несогласен с этой частью цитаты понятно?
Идем дальше.
[/quote]
Ну со статическими методами все понятно. Со всем другим можно поспорить,особенно про вирт. методы, но нет желания.
Цитата:
Достоинство 2: непонятное какое-то, а библиотек для C, значит, не существует. Или их очень-очень мало?
Процедурных библиотек существует не мало, но библиотек классов намного больше, а то "сразу не существует".
[quote=Green]
Хм... все равно, не понял, каких именно операторов и "некоторых конструкций" ?
[/quote]
Да это тяжело... Поробую объяснить. Использовать к примеру оператор new, вместо ф-ции malloc, и так далее по списку. Вообще-то я всегда считал, что все знают про улучшенный С, оказывается это не так.
Мне эта дискуссия порядком поднадоела, и спорить, и что-то доказывать, больше нет желания, остаюсь при своем мнении. Я высказал свою точку зрения, а если кто-то с ней не согласен жмите на линк с тремя буквами.
Цитата: Green
Хм... интересно, что подразумевается под понятиями "посылка сообщения" и "процедурная переменная" ?
Smalltalk был одним из первых объектно ориентированных языков. В статье видимо принята его терминология, где "посылка сообщения" эквивалентна нынешнему термину "вызов метода объекта". А "процедурная переменная" (видимо взята из Паскаля), по-моему, есть "небезопасная" вариация делегата.
З.Ы. to koval
Под улучшенным C понимается Objective-C?
Цитата: koval
Очень простая. При частом создании и удалении объектов, плохая фрагментация кучи.(Как ты все понимаешь буквально, и цепляешься к каждому слову)
При чем тут ООП?
В любом языке создаются и удаляются блоки данных.
Или ты считаешь, что при использовании ООП, блоки выделяются чаще?
Не вижу взаимосвязи между ООП и частотой создания/удаления объектов (блоков памяти). Это зависит лишь от реализации, но ни как от парадигмы. :)
Мы, к примеру, не используем STL в игровом коде в том числе как раз из-за фрагментации памяти. Но это не значит, что мы не используем C++ или ООП. Мы всего-лишь не используем библиотеку STL.
Цитата: koval
А что ты ожидаешь в качестве примера?
Два примера кода: один на языке поддерживающем ООП, другой - нет, где будет явно видно, что кода существенно больше и он запутаннее. Причем, задача решаемая кодом должна быть адекватна применению ООП. Т.е. к примеру, сложение двух int-ов - не есть адекватная задача.
Цитата: koval
Ну со статическими методами все понятно. Со всем другим можно поспорить,особенно про вирт. методы, но нет желания.
Думаю, сам понимаешь, как трактуется фраза "можно, но нет желания". :)
Всего то надо привести несколько строчек кода, показывающих разницу между вызовами функций и метода с т.з. производительности.
Nixus даже пример привел (http://forum.codenet.ru/showpost.php?p=226225&postcount=40), осталось только показать, в чем же разница.
Цитата: koval
Процедурных библиотек существует не мало, но библиотек классов намного больше, а то "сразу не существует".
Именно. Потому, что удобнее, понятнее и аккуратнее. Т.е. явно противоречит твоим п.1 и 2.
Цитата: koval
Да это тяжело... Поробую объяснить. Использовать к примеру оператор new, вместо ф-ции malloc, и так далее по списку. Вообще-то я всегда считал, что все знают про улучшенный С, оказывается это не так.
По какому списку? Огласите весь список.
Ты можешь дать четкое определение "улудшенного С", привести ссылки?
Нет? Значит, видимо, все "знают", но каждый думает свое.
Цитата: koval
Мне эта дискуссия порядком поднадоела, и спорить, и что-то доказывать, больше нет желания, остаюсь при своем мнении.
Кроме ссылки на явно спорную публикацию, никаких доказательств я не увидел. Интересно, ты своими словами четко, доходчиво и на конкретных примерах, можешь обосновать свое мнение по данному вопросу? Было бы интересно взглянуть на примеры, когда наследование сказывается на производительности. Интересно, как это выглядит на уровне команд ассемблера?
P.S. Без обид. Мне действительно интересно, на чем базируется твое мнение. Ну не только же на том, что кто-то так написал?
Вспомнился анекдот:
Цивилизация сделала электрические розетки недоступные большинству детей. Погибают самые одаренные.
Цитата: Green
Ты можешь дать четкое определение "улудшенного С", привести ссылки?
Что-то мне подсказывает, что тут подразумевается банальное написание С++ кода в Си-стиле, - то, чем по легендам, так сильно грешат Си-программисты "в первом поколении".
Цитата: InterWen
Что-то мне подсказывает, что тут подразумевается банальное написание С++ кода в Си-стиле, - то, чем по легендам, так сильно грешат Си-программисты "в первом поколении".
Так точно.
[quote=Green]
Два примера кода: один на языке поддерживающем ООП, другой - нет, где будет явно видно, что кода существенно больше и он запутаннее. Причем, задача решаемая кодом должна быть адекватна применению ООП. Т.е. к примеру, сложение двух int-ов - не есть адекватная задача.
[/quote]
Два примера не получится, нужно разработать два проекта один с использованием ООП другой без, вот тогда будут видны объемы кода. На С++ не писал уже 3 года, на С и того больше.
Собсна все.
Цитата: koval
Приведеные примеры вообще бред, естественно скорость ты не потеряешь используя ООП. Да это вообще не ООП! Если возьмешь и пересмотришь свой код ты это увидишь. Ты думаешь что это ООП, поменял слово struct на class.
Инкапсуляция есть, почему это не ООП? Может мы ООП по разному понимаем?
Цитата: koval
Скорость теряется именно при использовании наследования.
Утверждать, что при использовании наследования теряется скорость, это все равно что утверждать, что
Код:
struct Struct1
{
int X[5];
};
struct Struct2
{
Struct1 S;
} S;
int A = S.S.X[2];
{
int X[5];
};
struct Struct2
{
Struct1 S;
} S;
int A = S.S.X[2];
медленне чем
Код:
struct Struct2
{
int X[5];
} S;
int A = S.X[2];
{
int X[5];
} S;
int A = S.X[2];
Что есть несусветная глупость.
Цитата: koval
При разработки графики как таковой, каждый такт процессора на счету, по крайней мере раньше так было, до появления многоядерных процессоров. И только по этой причине при разработке игр пишется огромное кольчество ассемблерных процедур. Конечно без С++ тяжело обойтись, поэтому частенько да бы не писать на чистом С исползуют возможности С++, но без наследования, вообщем это факт и спорить тут не приходится.
Приина использования C скоре в том, что имена функции/методов в C++ очень сильно "каверкаются" при экспорте/импорте в угоду перегрузке.
Цитата: koval
Два примера не получится, нужно разработать два проекта один с использованием ООП другой без, вот тогда будут видны объемы кода.
Ну, за достаточно сложным примером с использованием ООП ходить далеко не нужно.
Там правда на C#, но не суть важна.
Интересно, сколько строк кода занял бы аналогичный пример на С, а также на сколько он был бы шустрее?
Цитата: hardcase
Ну, за достаточно сложным примером с использованием ООП ходить далеко не нужно.
Там правда на C#, но не суть важна.
Интересно, сколько строк кода занял бы аналогичный пример на С, а также на сколько он был бы шустрее?
Там правда на C#, но не суть важна.
Интересно, сколько строк кода занял бы аналогичный пример на С, а также на сколько он был бы шустрее?
Не думаю, что это будет интересным сравнением. Дело в том, что в приведенном примере мало используются преимущества ООП. По большому счету, при существовании необходимых библиотек (Regexp, Encoding, и т.д.), код на C будет выглядеть почти так же, единственное, что экземпляры структур будут передаваться отдельным параметром.
Для того, чтоб показать преимущества ООП нужно сосредоточиться на основных китах: инкапсуляция, наследование, полиморфизм, и как следствие,- абстракция. Поэтому в примере должны, видимо, как минимум присутствовать:
1) наследование реализации;
2) наследование интерфейса;
3) перегрузка операторов;
4) виртуальные методы;
5) шаблоны.
Перегрузка операторов и шаблоны к ООП не имеют отношения. Они еще в Аде 83-го года были.
Цитата: Archie
Перегрузка операторов и шаблоны к ООП не имеют отношения. Они еще в Аде 83-го года были.
Ну так и программирование существует давно, может, оно тоже к ООП не имеет отношения? :)
Перегрузка операторов, как пример инкапсуляции и абстрагирования.
Шаблоны, как пример абстракции. Кроме того, я очень сомневаюсь, что в Аде шаблоны играли ту же роль, что и в С++. Надо будет поднять информацию о шаблонах в Аде.
Цитата: Archie
Перегрузка операторов и шаблоны к ООП не имеют отношения. Они еще в Аде 83-го года были.
Насчет операторов не соглашусь. Перегрузка опраторов - есть не что иное как инкапсуляция, которая являтся одной из основ ООП.
Green,Nixus, перегрузка операторов - это никакая не инкапсуляция, а полиморфизм.
Извиняюсь за выражение, но IMHO в этой теме какой-то функционально-объектно-ориентированный понос начался...
Извиняюсь за выражение, но IMHO в этой теме какой-то функционально-объектно-ориентированный понос начался...
Цитата: vAC
Green,Nixus, перегрузка функций и операторов - это никакая не инкапсуляция, а полиморфизм.
Да ладно? С каких пор? Читаем википедию:
Цитата:
Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Операторы - это часть интерфейса, как и методы.
Цитата: vAC
Green,Nixus, перегрузка функций и операторов - это никакая не инкапсуляция, а полиморфизм.
Перегрузка операторов в классе может рассматриваться и как инкапсуляция, так и как полиморфизм, т.к. в данном случае эти понятия взаимосвязаны (понятием "интерфейс"):
Цитата:
Полиморфи́зм (в языках программирования) — взаимозаменяемость объектов с одинаковым интерфейсом.
Инкапсуля́ция — свойство языка программирования, позволяющее объединить данные и код в объект и скрыть реализацию объекта от пользователя. При этом пользователю предоставляется только спецификация (интерфейс) объекта. Пользователь может взаимодействовать с объектом только через этот интерфейс.
Я несколько усилил значение полиморфизма, применив термин абстракция. А теперь перечитываем внимательно:
Перегрузка операторов, как пример инкапсуляции и абстрагирования.
Вопросы, возражения?
Цитата: Green
А теперь перечитываем внимательно:
Перегрузка операторов, как пример инкапсуляции и абстрагирования.
Перегрузка операторов, как пример инкапсуляции и абстрагирования.
Я не могу осилить эту фразу...
Перегрузка операторов существует сама по себе, а ООП само по себе. ООП это просто концепция, можно и на C устроить инкапсуляцию и полиморфизм.
Цитата: Archie
Я не могу осилить эту фразу...
Перегрузка операторов существует сама по себе, а ООП само по себе.
Перегрузка операторов существует сама по себе, а ООП само по себе.
И что?
Ты каждое слово в отдельности воспринимаешь или пытаешься складывать их в предложения?
Перечитай пост и попробуй врубиться в его смысл прежде, чем спорить по каждому слову:
http://forum.codenet.ru/showpost.php?p=226334&postcount=55
Цитата: Archie
можно и на C устроить инкапсуляцию и полиморфизм.
Давай, покажи.
Вот и будет нам два примера кода: один на языке поддерживающем ООП, другой - нет, где будет явно видно, что кода существенно больше и он запутаннее.
P.S. Согласен с vAC, какой-то функционально-объектно-ориентированный понос начался...
Цитата: Archie
Перегрузка операторов существует сама по себе, а ООП само по себе.
Там где есть перегрузка операторов есть инкапсуляция. Т.к. применяя оператор над переменной ты интерпретируешь ее как объект, не важно из чего он состоит и как функционирует.
Цитата: Archie
ООП это просто концепция, можно и на C устроить инкапсуляцию и полиморфизм.
Можно. Кто против?
Цитата: Nixus
Там где есть перегрузка операторов есть инкапсуляция. Т.к. применяя оператор над переменной ты интерпретируешь ее как объект, не важно из чего он состоит и как функционирует.
А если я оператор с константой использую?
А если функцию вызываю и передаю ей переменную в аргументе, это тоже объект?
Ерунда какая-то.
В Ada83:
http://archive.adaic.com/standards/83lrm/html/lrm-06-07.html
2Green: Веди себя прилично, ты тут не один умный... ;)
Ещё раз пытаюсь обратить твоё внимание на то, в каком контексте говорилось про перегрузку операторов:
http://forum.codenet.ru/showpost.php?p=226334&postcount=55
http://forum.codenet.ru/showpost.php?p=226334&postcount=55
Имхо тема эта бесконечна, потому и холиварная.
[offtop]
:D Green, с наступающим!!! :D
[/offtop]
[offtop]
:D Green, с наступающим!!! :D
[/offtop]
Nixus, сокрытие - не обязательный атрибут перегрузки, поэтому я бы не мешал все в кучу. Если вы такой любитель википедии, то читайтездесь.
Green, согласен, но применив термин абстракция, вы не услили понятие полиморфизма.
Говоря о полиморфизме нельзя сказать, что это абстракция. Абстракция всего лишь характеристика сущности, которая отличает ее от других сущностей.
Green, согласен, но применив термин абстракция, вы не услили понятие полиморфизма.
Говоря о полиморфизме нельзя сказать, что это абстракция. Абстракция всего лишь характеристика сущности, которая отличает ее от других сущностей.
Цитата: Archie
А если я оператор с константой использую?
Приведи пример перегруженного оператора, в который можно передать только константы (не ссылки/адреса, а числовые константы).
Цитата: Archie
А если функцию вызываю и передаю ей переменную в аргументе, это тоже объект?
Это зависит от того, что за функция, как вызываешь и как передаешь.
Цитата: vAC
Nixus, сокрытие - не обязательный атрибут перегрузки, поэтому я бы не мешал все в кучу. Если вы такой любитель википедии, то читайтездесь.
Инкапсуляция - это не только сокрытие. Инкапсуляция предполагает сокрытие реализации и предоставлении интерфейса для работы над объектом. Операторы - это интерфейс, или ты с этим не согласен?
Цитата: vAC
Green, согласен, но применив термин абстракция, вы не услили понятие полиморфизма.
Говоря о полиморфизме нельзя сказать, что это абстракция. Абстракция всего лишь характеристика сущности, которая отличает ее от других сущностей.
Я не говорил, что абстракция - это полиморфизм.
Однако абстракция в программировании завязана на полиморфизм.
Цитата:
Под абстракциями здесь понимается умозрительное выделение круга взаимосвязанных свойств явления, которое помогает мысленно иметь дело с этим явлением не во всей его полноте и неразрывной связи с миром, а только с теми свойствами, которые важны для определенной, ограниченной области мысленных моделирований.
Круг взаимосвязанных свойств, которые важны для определенной, ограниченной области - это несколько шире, чем интерфейс, но общий смысл тот же: выделяется что-то "общее" и далее оперируется с этим "общим", не задумываясь о типе сущности и реализации.
Цитата: Nixus
Инкапсуляция - это не только сокрытие. Инкапсуляция предполагает сокрытие реализации и предоставлении интерфейса для работы над объектом. Операторы - это интерфейс, или ты с этим не согласен?
Оператор - это оператор, инетрфейс - это интерфейс. Зачем делать упор на "перегрузку оператора", когда она подразумевает всего лишь "интерфейс"?
Цитата: vAC
Оператор - это оператор, инетрфейс - это интерфейс. Зачем делать упор на "перегрузку оператора", когда она подразумевает всего лишь "интерфейс"?
Где я делаю упор? Я утверждаю, что перегрузка операторов есть часть инкапсуляции, и не утверждаю, что инкапсуляция это только перегрузка операторов.
Цитата: Nixus
Где я делаю упор? Я утверждаю, что перегрузка операторов есть часть инкапсуляции, и не утверждаю, что инкапсуляция это только перегрузка операторов.
Вот и делаете: "перегрузка операторов есть часть инкапсуляции". Уберите слово "операторов" и вы поймете о чем я говорю.
Вот казалось бы, причем здесь "будущее Delphi"... :))
Цитата: vAC
Вот и делаете: "перегрузка операторов есть часть инкапсуляции". Уберите слово "операторов" и вы поймете о чем я говорю.
А зачем уберать? Это будет не то, что я утверждал.
Во понафлудили. ))
Green-у +1 за грамотные разъяснения и терпение. Если честно просто поражаюсь некоторым аргументам оппонентов. Откуда они притянуты? )
Кстати, изучите уже значение термина "функциональное программирование". Особенно Nixus. Ибо он не имеет никакого отношения к тому, что вы им называете. Это скорее процедурно-модульное программирование называется.
Ато вон Одиссия уже запутали. ))
Green-у +1 за грамотные разъяснения и терпение. Если честно просто поражаюсь некоторым аргументам оппонентов. Откуда они притянуты? )
Кстати, изучите уже значение термина "функциональное программирование". Особенно Nixus. Ибо он не имеет никакого отношения к тому, что вы им называете. Это скорее процедурно-модульное программирование называется.
Ато вон Одиссия уже запутали. ))
Перегрузка операторов была позаимствована Бьёрном Страуструпом из языка Algol 68. Тогда парадигма ООП только начала формироваться. Бьёрн развил идею перегрузки - в C++ можно перегружать операторы и функции.
Это только информация к размышлению, выводы делайте сами :-)
Это только информация к размышлению, выводы делайте сами :-)
Какие блин выводы? )))
Че все привязались к перегрузке?
Вызовы функций тоже появились гораздо раньше и чо теперь? ))
Че все привязались к перегрузке?
Вызовы функций тоже появились гораздо раньше и чо теперь? ))
Цитата: aks
Кстати, изучите уже значение термина "функциональное программирование". Особенно Nixus. Ибо он не имеет никакого отношения к тому, что вы им называете.
С какого бока в этом флейме у Вас выплыло функциональное программирование? По-моему тут речь шла про парадигмы - структурное против объектно-ориентированного.
Цитата: aks
Че все привязались к перегрузке?
Вызовы функций тоже появились гораздо раньше и чо теперь? ))
Вызовы функций тоже появились гораздо раньше и чо теперь? ))
Здесь затронули тему перегрузки, и спорили о её принадлежности к ООП. Про вызовы функций, пока ещё речь не шла.
Насчёт, привязались - так и Вы от топика далеко ушли.