Как ты связал простоту и краткость? Вообще не связанные вещи. Докторская Ландау занимала пять страниц. Теорема Ферма вообще на полях книги была написана.
И с чего ты вдруг решил, что «раз на простом примере… значит». Нифига не значит. Hello World на MFC займет сотни строк. И что? Да ничего
Здравствуйте, Shmj, Вы писали:
S>Видно что ООП языки — примерно одинаковой компактности, в то время как язык без ООП даже на простейшем примере потребовал писать почти в 2 раза больше строк кода.
Хм, а у меня на C чуть покороче получилось:
#include <stdio.h>
int main()
{
printf("Text=text\nIsChecked=1\n");
return 0;
}
Здравствуйте, Shmj, Вы писали: S>Давайте пока с простейшего примера, потом, возможно, добавлю чуть интереснее: S>C# 42 строки S>C++ 59 строк S>Rust 73 строки S>Выводы какие? Даже на простейшем примере видно удобство ООП. А теперь представьте что пример будет реальным — сразу 50 тыс. строк превращаются в 100 тыс.
Никакие. Язык без ООП lua:
require "object"
Widget={ render=function(self) print(self.name.."="..self.id) end }
TextEditWidget=object(Widget) { render=function(self) inherited(self,"render")() print("Text="..self.text) end }
CheckWidget=object(Widget) { render=function(self) inherited(self,"render")() print(("IsChecked=%s"):format(self.is_checked)) end }
local widgets={}
table.insert(widgets, object(TextEditWidget) { id=1, name="Text1", text="text" })
table.insert(widgets, object(CheckWidget) { id=2, name="Check1", is_checked=true })
for i,widget in pairs(widgets) do widget:render() end
10 строк и 12 строк эмуляция ооп
object.lua
function object(parent)
return function(prm)
local res=setmetatable(prm or {},{__index=parent})
if res.init then res:init() end
return res
end
end
function inherited(obj,fn)
local class=(getmetatable(obj) or {__index={}}).__index
local parent=(getmetatable(class) or {__index={}}).__index
return function(...) if parent~=nil then local f=parent[fn] if f~=nil then return f(obj,...) end end end
end
Здравствуйте, Разраб, Вы писали:
Р>ps ооп в расте лично мне понравилось. trait это как интерфейс и расширение в одном флаконе.
P.P.S. traits в rust во многом сделаны по подобию классов типов из хаскеля. Названия терминов только более человеческие. Вот, например, trait object, вы не поверите, это что-то из разряда "existential quantification" в хаскеле, если я сам уже не забыл и не стал путаться в хаскелевской терминологии, а это возможно
p.p.p.s. Название написал со второй попытки — таки перепутал
Здравствуйте, Shmj, Вы писали:
S>Или если я не прав — то ткни носом
В цитате-то OK, но очень удивительно, как читая правильные вещи, вы не понимаете что это и где это в вашем коде.
В общем, я давно придерживаюсь мнения, что далеко не всех людей можно научить программировать. А из тех, кого можно научить программировать, далеко не всех можно научить программировать на C++ (а программировать нормально на чистом Си можно научить вообще исчезающе малое количество). Обычно за такой шовинизм мне прилетает. Но вы являетесь отличным доказательством того, что я прав
S>а не прячься за, мол, учить бесплатно.
Вообще-то когда мы обучаем людей пользоваться нашими инструментами, то иногда (к счастью иногда) приходится и объяснять какие-то вещи из C++. Делается это все за деньги.
Но, может быть здесь найдется добрая душа, которая объяснит вам в чем дело. Забесплатно.
Здравствуйте, Shmj, Вы писали:
S>Видно что ООП языки — примерно одинаковой компактности, в то время как язык без ООП даже на простейшем примере потребовал писать почти в 2 раза больше строк кода. Хотя там еще добавляется многословность в связи с Option — но кто им виноват, что не использовали ? как в C# на уровне языка, а то постоянно лепят свой Option.
Дык примеры неравноценны. Давай в крестах с опционами покажи. Ну и в русте куча лишних строк изза того что не использовано .unwrap_or()
Ты ставишь необходимость ООП в аксиоматику и доказываешь, что код на языках, поддерживающие ООП, выглядит компактней.
С этим, конечно, спорить просто глупо.
Лично я считаю, что полновесный ООП уместен в малом числе случаев. Я вообще не припоминаю, когда последний раз я бы писал какую-то иерархию классов, кроме как для удовлетворения идиотского фреймворка.
Поэтому ООП я могу сравнить с такой фичей интересной, под названием "множественная диспетчеризация". В ООП выбор реализации метода зависит от типа первого аргумента this. Это одиночная диспатчеризация. Множественная диспатчеризация расширяет этот выбор до произвольного числа аргумнентов. В частности есть известный паттерн Визитёр, который, используя одиночную диспатчеризацию (к примеру C++, как в классической книге Четырёх) реализует двойную диспатчеризацию (ну и по аналогии можно реализовать произвольную диспатчеризацию). И там, где у языка с двойной диспатчеризацией будет очень простой код, этот самый Визитёр городит огромную кучу дополнительного кода.
Но, тем не менее, множественная диспатчеризация пока не пробралась ни в один из общеиспользуемых языков программирования. Потому, что задачи, которые она решает, слишком редко встречаются и это все понимают.
По поводу ООП такого консенсуса нет, это я готов признать. Но своё мнение я высказал.
Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации. Также может быть полезен синтаксический сахар, для замены наследования реализаций композицией. Вот это подмножество действительно полезно и часто применимо. А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее. Вреда больше, чем пользы. И, что забавно, Go, Rust как раз и реализуют указанное подмножество.
Видно что ООП языки — примерно одинаковой компактности, в то время как язык без ООП даже на простейшем примере потребовал писать почти в 2 раза больше строк кода. Хотя там еще добавляется многословность в связи с Option — но кто им виноват, что не использовали ? как в C# на уровне языка, а то постоянно лепят свой Option.
Выводы какие? Даже на простейшем примере видно удобство ООП. А теперь представьте что пример будет реальным — сразу 50 тыс. строк превращаются в 100 тыс.
Здравствуйте, T4r4sB, Вы писали:
TB>Дык примеры неравноценны. Давай в крестах с опционами покажи. Ну и в русте куча лишних строк изза того что не использовано .unwrap_or()
Но вообще лучше убрать Option — иначе будем обсуждать иной вопрос, а не сабжевый. Можно сказать что Option протек случайно — не хотел писать конструктор в C#-версии и просто на автомате применил nullable-типы, а в Rust это потребовало писать Option.
Но вот взять базовый класс и вирт. функции с реализацией по умолчанию — в Rust для каждой из них нужно будет писать минимум 1 строчку кода для каждой функции в наследнике. Если, конечно, нет придумать спец. атрибут.
S>Выводы какие? Даже на простейшем примере видно удобство ООП. А теперь представьте что пример будет реальным — сразу 50 тыс. строк превращаются в 100 тыс.
А какую проблему пытаешься решить? Сэкономить место в репе или время набора текста?
Пока что ничего кроме как «и чо?» не приходит в голову в качестве ответного комента.
S>Выводы какие? Даже на простейшем примере видно удобство ООП. А теперь представьте что пример будет реальным — сразу 50 тыс. строк превращаются в 100 тыс.
Здравствуйте, Shmj, Вы писали:
S>>Это вам ChatGPT подсказал такую срань: пометить подобного вида конструктор как noexcept?
S>Это я чего-то попутал на скорую руку. А потом уже лень было исправлять, думал никто не заметит.
S>Для vector нужно ставить на конструктор перемещения, иначе при расширении будет использовать копирование вместо перемещения.
Здравствуйте, so5team, Вы писали:
S>>Для vector нужно ставить на конструктор перемещения, иначе при расширении будет использовать копирование вместо перемещения. S>
Здравствуйте, Shmj, Вы писали:
S>>>Для vector нужно ставить на конструктор перемещения, иначе при расширении будет использовать копирование вместо перемещения. S>>
S>Готов выслушать конкретику.
А я не готов учить вас забесплатно. Вы ChatGPT деньги платите, вот пусть ChatGPT вас и учит.
S>Вот пример, который это демонстрирует: https://metanit.com/cpp/tutorial/14.4.php
Вот уж в прямом смысле "смотришь в книгу, а видишь..."
Здравствуйте, so5team, Вы писали:
S> Вот уж в прямом смысле "смотришь в книгу, а видишь..."
Да вот же:
Почему здесь используется конструктор копирования, а не конструктор перемещения, который в данном случае был бы более предпочтителен? Дело в том, что вектор не уверен, что конструктор перемещения не сгенерирует исключение и в этом случае прибегает к конструктору копирования.
Но в данном случае у нас нет в конструкторе перемещения каких-то моментов, которые могли бы привести к генерации исключения. Поэтому определим конструктор с ключевым словом noexcept:
Тут не учить за бесплатно — а просто признай что не знал этого — не сталкивался. И хотел как бы покичиться — а вышло наоборот, что опозорился.
Или если я не прав — то ткни носом, а не прячься за, мол, учить бесплатно.
Здравствуйте, student__, Вы писали:
S>>Но, может быть здесь найдется добрая душа, которая объяснит вам в чем дело. Забесплатно.
__>А зачем вообще существуют форумы, типа того же RSDN? __>Здесь же тоже бесплатно отвечают на вопросы. __>Во всяком случае, я ценников на ответах не видел.
Ага. А потом приходит Шмыж и все портит. Он уже знаменит (по крайней мере в форумах по C/C++) своим нежеланием воспринимать то, что ему пытаются объяснить (а делать это пытались неоднократно). Так что дело именно в нежелании помогать конкретному персонажу, а не вообще.
Здравствуйте, Shmj, Вы писали:
S>Но вообще лучше убрать Option — иначе будем обсуждать иной вопрос, а не сабжевый.
ну уберите и получите сразу уменьшение количества строк. И код будет уже сравним как минимум с С++.
S>Но вот взять базовый класс и вирт. функции с реализацией по умолчанию — в Rust для каждой из них нужно будет писать минимум 1 строчку кода для каждой функции в наследнике. Если, конечно, нет придумать спец. атрибут.
почему? И в Rust можно для характеристики прописать какой-то метод по default.
Здравствуйте, Shmj, Вы писали:
S>На C будет примерно так:
И не лень тебе было портировать эту простыню, лучше б подумал немножко, что тебе хотели сказать.
Мой код делает ровно тоже, что и твой. И проще и удобнее сопровождать.
Вот когда сложность задачи становится такой, что нахрапом ее не закодить, когда сущности и их связи перестают помещаться у тебя в голове, когда приходится делать много похожих вещей,
тогда и имеет смысл усложнять архитектуру, и вот там-то и становится понятным, какие фичи полезны и удобны, а какие не очень.
Здравствуйте, graniar, Вы писали:
G> G>И не лень тебе было портировать эту простыню, лучше б подумал немножко, что тебе хотели сказать.
Мне стоило лишь отдать приказ — и за меня все сделал раб мой GPT. Заняло 10 сек. моего времени.
G>Мой код делает ровно тоже, что и твой. И проще и удобнее сопровождать.
Но ведь смысл кода — продемонстрировать возможности языка по реализации Liskov substitution principle.
Здравствуйте, so5team, Вы писали:
vsb>>Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации...А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее.
S>Э... А нет ли здесь противоречий? Или в первом предложении под словом "реализации" подразумевалось не 'наследование реализации'?
Здравствуйте, vsb, Вы писали:
vsb>>>Лично я считаю полезным подмножеством ООП интерфейсы, наследование интерфейсов, реализации...А вот добавлять в это подмножество полновесное наследование реализаций (или, не приведи господи, множественное наследование реализаций) — лишнее.
S>>Э... А нет ли здесь противоречий? Или в первом предложении под словом "реализации" подразумевалось не 'наследование реализации'?
vsb>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".
Понятнее не стало. А что такое "реализации" в контексте ООП?
Здравствуйте, so5team, Вы писали:
vsb>>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".
S>Понятнее не стало. А что такое "реализации" в контексте ООП?
Вот пример на Java. На С++ интерфейс это класс без данных и с полностью виртуальными методами.
Здравствуйте, vsb, Вы писали:
vsb>>>Подразумевалось "интерфейсы", "наследование интерфейсов", "реализации".
S>>Понятнее не стало. А что такое "реализации" в контексте ООП?
vsb>Вот пример на Java. На С++ интерфейс это класс без данных и с полностью виртуальными методами.
Что такое интерфейсы в Java понятно. Просто странно, что наличие такой штуки, как "реализация интерфейса" рассматривают как особенность ООП, да еще и положительную особенность.