Здравствуйте, igna, Вы писали:
I>Является ли STL объектно-ориентированной библиотекой?
STL в основном функционально ориентированная библиотека. Просто в виду того, что С++ мультипарадгмный язык в котором одинаково плохо поддерживаются все парадигмы, фунциональная тоже выглядит убого. В прочем костыли в виде Буста немного исправляют положение.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, igna, Вы писали:
I>Является ли STL объектно-ориентированной библиотекой?
Нет. Сама идея STL в значительной мере ортогональна идеям ООП; автор всегда рассматривал ее как набор универсальных алгоритмов, и сильно плевался по поводу самой парадигмы ООП, которая не позволяет отделить логику от поведения какого-то объекта. STL идеологически гораздо ближе к функциональному программированию.
Реализация STL в С++ естественно использует объекты; но это скорее вынужденная мера, связанная с особенностями языка C++. Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, igna, Вы писали:
G>>В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
I>Хм, и это несмотря на то, что ты знаешь, что сам Степанов не считает свою STL объектно-ориентированной. Может быть дело в определении, вот например что написал Саттер:
I>
I>Well, what is object orientation, anyway? Even at this late date, if you ask 10 people, you're likely to get 15 different answers.
I>Для меня ООП на C++ приблизительно равно использованию слова virtual, хотя конечно и на С можно сэмулировать объектную ориентированность, и напротив на C++ можно писать virtual везде, где позволяет компилятор не пользуясь возможностями, которые этот самый virtual дает, но в целом для меня virtual == OOP, а для тебя скорее всего нет.
Вообще — привязывать определение ООП к языку — неправильно. Тем более, что все необходимые определения не зависящие от языков существуют. Есть определение объектной системы Кея, есть классическое определение ООП (три пункта), есть понятие АДТ — все они не зависят от языка, и связаны друг с другом.
Определение Кея по пунктам — слева, справа я ставлю эквивалентные утверждения и замечания:
1. Объект имеет изменяемое состояние == объект имеет identity.
2. Объекты обмениваются сообщениями == нет прамого доступа к состоянию объекта, есть только заданный набор операций над ним (АДТ)
3. Объект сам решает, как обработать сообщение => это относится ко всем пунктам определения — "инкапсуляция" (операции определены в объекте/классе), "полиморфизм" (одно и то же сообщение может быть послано объектам разных типов == один "метод" может срабатывать для объектов разных классов и может быть определен в разных классах по разному), и "наследование" — как способ обеспечения динамического полиморфизма в строготипизированном языке.
О "наследовании" и слове "virtual" в определени Кея не говорится ни слова. При этом — именно Аллан Кей у нас "папа" ООП. К примеру — по определению Кея — COM является объектной системой (а не только Java c C++). И это правильно. Общее во всех определениях, теориях, и встречающиеся во всех языках в том или ином виде — можно выделить следующее:
1. Понятие объекта — это АТД (абстрактный тип данных) с инкапсулированным состоянием и "идентити".
2. Понятие полиморфной функции — это функция, которая может быть применена к аргументам разных типов (объект, у которого вызван метод, является неявным аргументом функции-метода). Полиморфизм бывает параметрический (одно действие на все типы аргументов), или ad-hoc (разное действие на разные типы аргументов — вот он ваш virtual).
Наследование же не является непременным атрибутом "объектности". В строготипизированных языках наследование необходимо для обеспечения динамического полиморфизма. В динамически типизированных языках — можно много и без этого.
Объекты Степанов использует (итераторы, контейнеры). И никуда он от них не денется. Он может не называть объекты объектами — это не меняет суть дела, объекты они объекты и есть — в них завернуто состояние и к нему нет прямого доступа. Самый пренастоящий объект. Далее начинается функциональщина. "Алгоритмы" — являются полиморфными функциями (реализовано как шаблонные функции). Степанов также применяет замыкания, моделируя их (угадай чем?) опять объектами (функторами). Однако — полиморфизм STL — статический, он работает во время компиляции, а в динамике не работает. Поэтому от наследования и виртуальных функций все равно никуда не деться при проектировании мало-мальски сложной системы — что бы Степанов не говорил (как только понадобится во время выполнения делать разные действия для разных типов объектов — как приплыли. Представим на секунду, что в красивой STL-ной коллекции лежат геометрические фигуры разных типов. И весь красивый выдуманный Степановым generic programming идет лесом).
Что имеем в результате по существу:
1) Степанов предлагает применять функции высокого порядка, generic-функции, и замыкания, и говорит, что это круто. Он прав, это круто, — что вам подтвердит любой программер знающий функциональные языки — там на этом добре все построено. Собственно, Степанов не с потолка это взял — он знает LISP. Так что STL — функциональная библиотека.
2) STL при этом — объектная библиотека. Объектов и полиморфизьму там есть дофигища. Без объектов не получится абстракции контейнера, на которой построен STL — хоть в лепешку расшибись. Функторы — ладно, это все-таки не объекты, а больше замыкания.
3) Вот если бы нормальный pattern-matching в С++ был — то тогда можно было бы реально без наследования обойтись. А так — не выйдет от наследования избавится. Хотя применение generic-функций и функций высокого порядка, безусловно, сильно сокращает сложность иерархий наследования.
Здравствуйте, Sinclair, Вы писали:
S>Нет. Сама идея STL в значительной мере ортогональна идеям ООП; автор всегда рассматривал ее как набор универсальных алгоритмов, и сильно плевался по поводу самой парадигмы ООП, которая не позволяет отделить логику от поведения какого-то объекта. STL идеологически гораздо ближе к функциональному программированию.
S>Реализация STL в С++ естественно использует объекты; но это скорее вынужденная мера, связанная с особенностями языка C++. Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось. Итераторы — абстракция контейнера (известная еще с 70-х годов). Устроены разные итераторы по разному, имеют стандартный интерфейс. Итераторы — это самые-пресамые настоящие объекты, никакого отношения к ФП они не имеют. "Алгоритмы" формулируются над итераторами. Единственное что взято из ФП — это функции высокого порядка, которые действительно эмулирутся на функторах и шаблонных функциях. Все.
В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
Здравствуйте, machine3000, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
G>>Да. Ну и что? Ты это к чему? G>>Инженеру неплохо понимать, как он пишет код, чтобы его код был хорош. M>Хорош в каком отношении? Это можно измерить по какими-то описанным методикам? Или речь идёт о том, что "Gaperton" должен посмотреть на этот код и, как истиный ценитель ООП, сказать, да он хорош.
Можно. Стоимость внесения изменений в код является весьма неплохой характеристикой качества кода. Ее можно измерить. Вообще — хороший код прежде всего прост для человеческого понимания.
Мне не нравится, как вы ведете дискуссию. Не надо приписывать мне авторство выдуманных вами глупостей, чтобы потом с этими глупостями спорить, ладно? Например — я нигде не говорил, что если код ООП-шный, то это означает, что он хорош. Это первое. Отзываться в третьем лице о человеке в разговоре, как делаете вы — хамство, это второе. А я не люблю когда мне хамят.
G>>А не просто колбасить код — это любой дурак умеет. M>Хорошо, но если инженер не "просто" колбасит код, а делает это руководствуясь какими-то своими критериями, например как Степанов, и этот код вдруг по мнению "Gaperton" не достаточно объектно-ориентированный, означает ли это, что код плох?
Насчет STL, который написал Степанов — я достаточно ясно выразился в первом письме, что STL с моей точки зрения "хорош". Так что претензия и подковырка в вашем вопросе меня искренне изумляет — она мне не понятна. Вы читайте посты прежде чем отвечать. Там пишут иногда удивительные вещи.
G>>А в спорах рождается истина. К слову — я вообще перестал понимать, в чем ты меня хочешь убедить. Вроде как ты со мной споришь, нет? M>Я хотел сказать тоже самое, что сказано в цитате, приведённой "igna". Мнения о том, где ООП, а где нет, различаются у разных людей. А раз так, об этом говорить с точки зрения производственного процесса бессмысленно.
Хочу обратить ваше внимание на прелюбопытнейший факт — мнения людей по очень многим и самым разным вопросам различаются у разных людей. А раз так, то какие будут выводы? Я скажу так — если вы считаете, что говорить о чем-то бессмысленно — не говорите.
M>К слову, я вашу точку зрения и методы ведения дискуссии хорошо понимаю.
А я вашу — нет. Мне, в частности, непонятно, почему бы сразу, по простому, не сказать того, что вы хотите сказать ("то же самое, что сказано в цитате, приведенной igna"). Нет, надо зачем-то обязательно в двадцать постов вокруг да около походить. Разговор довольно дурацкий. Я со своей стороны его заканчиваю — надоело.
Здравствуйте, igna, Вы писали:
I>Является ли STL объектно-ориентированной библиотекой?
Как то раз чуваки заменили foo(&bar) на bar.foo() и сказали "вот ООП". Другие чуваки посмотрели ассемблерный листинг и сказали "ерунда", это абсолюдно одно и тоже. Вот если написать "virtual foo()" — это ООП. Третьи чуваки возразили, но полиморфизм можно реализовать и вручную другими способами, так что не важно как и что писать, главное чтоб был полиморфизм. Но нашлись и четвёртые. Они стали утверждать что далеко не всякий полиморфизм объектно-ориентированный и принялись смаковать тонкости полиморфизма...
А как-то раз собравшись все вместе они решили выяснить, объектно-ориентированна ли STL.
Здравствуйте, machine3000, Вы писали:
M>Здравствуйте, Gaperton, Вы писали:
G>>Можно. Стоимость внесения изменений в код является весьма неплохой характеристикой качества кода. Ее можно измерить. Вообще — хороший код прежде всего прост для человеческого понимания. M>Интересная тема. Но если вы разговор продолжать не хотите...
Ок, если вы меня в третьем лице называть не будете, то продолжим. Тема действительно интересная. Что вы думаете по этому поводу?
G>>Мне не нравится, как вы ведете дискуссию. Не надо приписывать мне авторство выдуманных вами глупостей, чтобы потом с этими глупостями спорить, ладно? Например — я нигде не говорил, что если код ООП-шный, то это означает, что он хорош. M>Но вы говорили, что хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП. А также, что инженеру неплохо понимать, как он пишет код, чтобы его код был хорош. Если эти фразы рассматривать в одном контексте, тут можно сделать кой-какие выводы. Ну если вы действительно потеряни нить разговора, то уж извините.
ООП, ФП — это парадигмы. Код — это код, он может быть хорошим или плохим, будучи оформленным в рамках любой парадигмы. Более того — код вообще не обязан строго следовать любой из них — умение в нужный момент отступать от правил гораздо важнее, чем слепо им следовать. Для этого надо хорошо знать эти правила, понимать границы применимости, а также сильные и слабые стороны технологий применительно к конкретному случаю. То есть, инженеру неплохо понимать, как он пишет код, и, в частности, не повредит умение разбираться, где ООП, а где нет. Это, впрочем, далеко не единственное, в чем не повредит разбираться.
G>>Насчет STL, который написал Степанов — я достаточно ясно выразился в первом письме, что STL с моей точки зрения "хорош". Так что претензия и подковырка в вашем вопросе меня искренне изумляет — она мне не понятна. Вы читайте посты прежде чем отвечать. Там пишут иногда удивительные вещи. M>Это было развитие предыдущего тезиса. Кроме того вы сами признавались, что считаете STL редким случаем удачного сочетания на микроировне ФП и ООП (кажется так). Из этого ничего не следует?
Один мой друг говорил: "главное — озадачить собеседника." Вам это удалось. И что из этого следует?
STL хорош не потому, что это сочетание ФП и ООП. STL хорош потому, что прост, удобен, красив, и понятен. В STL нет ничего лишнего — ни добавить, ни прибавить. Вот когда мы попытаемся разобраться, как STL устроен, на каких принципах, и на что он похож — то станет видно, что все в сущности проще, настолько просто, что не надо никаких "новых парадигм" выдумывать, вроде generic programming. Станет понятно, например, что в таком стиле легко писать на JavaScript — легче, чем на С++, и безо всяких темплейтов. Теория нужна, чтобы упрощать вещи, — в мире мало оригинальных уникальных штук, все основано на относительно небольшом наборе принципов. Понимание этих принципов делает вас более хорошим программистом на любом языке.
G>>Хочу обратить ваше внимание на прелюбопытнейший факт — мнения людей по очень многим и самым разным вопросам различаются у разных людей. А раз так, то какие будут выводы? Я скажу так — если вы считаете, что говорить о чем-то бессмысленно — не говорите. M>Бессмысленно спорить о границах парадигм. Я об этом не слова не сказал. И долго пытался вас в этом убедить. Ну не получается
На мой взгляд — отнють не бессмысленно. См. выше.
M>>>К слову, я вашу точку зрения и методы ведения дискуссии хорошо понимаю. G>>А я вашу — нет. Мне, в частности, непонятно, почему бы сразу, по простому, не сказать того, что вы хотите сказать ("то же самое, что сказано в цитате, приведенной igna"). Нет, надо зачем-то обязательно в двадцать постов вокруг да около походить. Разговор довольно дурацкий. Я со своей стороны его заканчиваю — надоело. M>Я вам в первом посте выдал, что вопрос о границах парадигмы ООП — философский, а не технический. Но вы ж сразу заговорили о прыжках в окно. Я не против пообщаться в любом жанре.
Прыжки в окно — я сказал к тому, что надо своей головой думать, а не приводить цитаты из Карла Маркса и прочих "классиков" на любой случай. Мало ли, что Степанов думает. У толкового инженера должна быть своя голова на плечах. Понимать, что говорит тот же Степанов, это совсем не тоже самое, что "верить тому, что говорит Степанов". Если вы понимаете — вы можете позволить себе в чем-то соглашаться, а в чем-то нет. И для вас лично это будет гораздо ценнее. Как и для собеседников — они беседуют с вами, а не со Степановым. Впрочем, это надо адресовать скорее Синклеру, а не вам — он привел цитату. Но, я думаю, Синклер и так все понимает — он у нас sharp.
Здравствуйте, Kluev, Вы писали:
M>>Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что надо было включать в 1999.
K>Так включат или нет?
Обязатльно в 2109-ом.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Gaperton, Вы писали:
G>>Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось. S>Вот точка зрения основного автора STL на отличие того, чем он занимается, от ООП:
Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП. У него получилась классная библиотека, за что ему спасибо. Это не означает, что если он скажет тебе какую-нибудь глупость — например, выпрыгнть в окно, то надо не раздумывая так и делать. Естественно, ему хочется претендовать на то, что он изобрел радикально новый, принципиально отличный от всего существующего подход. Но он в этом не прав — в мире вообще очень мало по настоящему оригинальных вещей.
Вот смотри: S>
However, there is a radical difference. Object-oriented programming emphasizes the syntax of linguistic elements of the program construction. You have to use inheritance, you have to use classes, you have to use objects, objects send messages. Generic programming does not start with the notion of whether you use inheritance or you don't use inheritance. It starts with an attempt to classify or produce a taxonomy of what kinds of things are there and how they behave.
Ну во-первых, наследование без необходимости никто использовать не обязан (кстати, в реализациях STL активно испльзуется наследование. Рекомендую заглянуть). Более того, в определении объектной системы Алана Кея нет никакого упоминания о наследовании.
Во-вторых, я не понимаю трагизма того, что мне надо использовать классы и объекты. Если Степанову не нравится названия "класс", "объект", "сообщение" — пусть назовет хоть "жопой". В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет. Объект не перестанет быть объектом, как его не называй. А вот без классов можно обойтись, и ничего страшного не случится. Например, в динамическом языке. И система все равно будет объектной по определению Кея.
В третьих, когда он переходит к описанию подхода generic programming он почему-то ловко переходит на процесс проектирования (кстати, так же и объектная система проектируется — ну просто слово в слово). Непонятно, кого он хочет обмануть. ООП (и проектирование ОО системы) тоже начинается совсем не с того, надо нам или не надо применять наследование, и куда все-таки вкрячить эти дурацкие классы (это у студентов он только так начинается, да и то только у самых тупых).
Так что это мнение, Синклер, во-первых — мнение Степанова, если я не ошибаюсь, а не твое, во вторых, ну никак не подтверждает твой тезис.
Здравствуйте, Sinclair, Вы писали:
S>Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
VladD2 wrote: > M>>Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что > надо было включать в 1999. > K>Так включат или нет? > Обязатльно в 2109-ом.
Не, не успеют.
Возможно, к 9998 году и справятся и включат в Стандарт заодно и с фиксом
проблемы Y10K (и выпуском HTML 5.0).
Здравствуйте, machine3000, Вы писали:
M>Здравствуйте, RailRoadMan, Вы писали:
RRM>>Я согласен с тобой, просто мне кажется, что когда Степанов говрил, что STL построена не на ООП, он имел в виду "классический ООП раньнего периода С++", того ктр построен на наследовании и виртуальных функциях, и ктр какое-то время и считался ООП (для С++ по крайне мере). Так вот такого ООП в STL нет, тут степанов прав, просто он именно таким в тот момент считал ООП в С++. Но это исключительно ИМХО
M>Степанов претендовал на изобретение новой парадигмы — "generic programming". И я его всецело поддерживаю в этом вопросе. Однако, следует учитывать мнение других людей, которые рассудили так: "Что, новая парадигма? Мы что, не в той парадигме всю жизнь работали? Да не какая это не новая парадигма. Всё это уже было. Вот ООП, вот ФП, а всё остальное — детали."
Весь этот спор не имеет пактического смысла. Степанов и те кто с ним спорит, имеют в виду разное.
Степанов сказав, что STL не ООП. Он хотел подчеркнуть, что в основе лежит generic programming.
Но те, кто с ним спорит, воспримают его слова, как будто он сказал "В STL нет ничего от ООП и близко, и даже думать о таком кощунственно". Но он же не это сказал.
Мораль:
1) В основе STL лежит generic programming, а не ООП
2) ООП там присуствует, не очень силль но тем не менее.
В таком смысле ответ на изначальный вопрос будет: Да в STL используются объекты (ну или ООП), но это в ней не самое главное.
Здравствуйте, FR, Вы писали:
FR>>>D не смотрел?
L>>А там есть замыкания?
FR>Есть, прямо по твоим требованиям, с UB при использовании стековых переменных.
Да. Это важно. Иначе жизнь станет скучной.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Можно. Стоимость внесения изменений в код является весьма неплохой характеристикой качества кода. Ее можно измерить. Вообще — хороший код прежде всего прост для человеческого понимания.
Интересная тема. Но если вы разговор продолжать не хотите...
G>Мне не нравится, как вы ведете дискуссию. Не надо приписывать мне авторство выдуманных вами глупостей, чтобы потом с этими глупостями спорить, ладно? Например — я нигде не говорил, что если код ООП-шный, то это означает, что он хорош.
Но вы говорили, что хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП. А также, что инженеру неплохо понимать, как он пишет код, чтобы его код был хорош. Если эти фразы рассматривать в одном контексте, тут можно сделать кой-какие выводы. Ну если вы действительно потеряни нить разговора, то уж извините.
G>Насчет STL, который написал Степанов — я достаточно ясно выразился в первом письме, что STL с моей точки зрения "хорош". Так что претензия и подковырка в вашем вопросе меня искренне изумляет — она мне не понятна. Вы читайте посты прежде чем отвечать. Там пишут иногда удивительные вещи.
Это было развитие предыдущего тезиса. Кроме того вы сами признавались, что считаете STL редким случаем удачного сочетания на микроировне ФП и ООП (кажется так). Из этого ничего не следует?
G>Хочу обратить ваше внимание на прелюбопытнейший факт — мнения людей по очень многим и самым разным вопросам различаются у разных людей. А раз так, то какие будут выводы? Я скажу так — если вы считаете, что говорить о чем-то бессмысленно — не говорите.
Бессмысленно спорить о границах парадигм. Я об этом не слова не сказал. И долго пытался вас в этом убедить. Ну не получается
M>>К слову, я вашу точку зрения и методы ведения дискуссии хорошо понимаю. G>А я вашу — нет. Мне, в частности, непонятно, почему бы сразу, по простому, не сказать того, что вы хотите сказать ("то же самое, что сказано в цитате, приведенной igna"). Нет, надо зачем-то обязательно в двадцать постов вокруг да около походить. Разговор довольно дурацкий. Я со своей стороны его заканчиваю — надоело.
Я вам в первом посте выдал, что вопрос о границах парадигмы ООП — философский, а не технический. Но вы ж сразу заговорили о прыжках в окно. Я не против пообщаться в любом жанре.
Здравствуйте, Gaperton, Вы писали:
G>Объекты Степанов использует (итераторы, контейнеры). И никуда он от них не денется. Он может не называть объекты объектами — это не меняет суть дела, объекты они объекты и есть — в них завернуто состояние и к нему нет прямого доступа. Самый пренастоящий объект.
Ни состояние, ни отсутствие прямого доступа нафик для STL не нужны. То есть вообще. Это сделано только для удобства в контексте C++ *уровня понимания первой половины 90-х*. Сейчас хорошо понятно, как написать все то же безо всякого состояния и вообще без потерь эффективности.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Объекты Степанов использует (итераторы, контейнеры). И никуда он от них не денется. Он может не называть объекты объектами — это не меняет суть дела, объекты они объекты и есть — в них завернуто состояние и к нему нет прямого доступа. Самый пренастоящий объект.
A>Ни состояние, ни отсутствие прямого доступа нафик для STL не нужны. То есть вообще. Это сделано только для удобства в контексте C++ *уровня понимания первой половины 90-х*. Сейчас хорошо понятно, как написать все то же безо всякого состояния и вообще без потерь эффективности.
Смелое утверждение. Человек, которому это понятно, может претендовать на премию Тьюринга, я думаю. Но только в том случае, если он еще кому-нибудь в состоянии объяснить, что же именно ему понятно, без этого никак. Не объясните, как это написать безо всякого состояния и с прямым доступом?
Ну, итераторы, положим, можно сделать stateless без потери эффективности. Но и только. Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу.
Здравствуйте, Gaperton, Вы писали:
G>Ну, итераторы, положим, можно сделать stateless без потери эффективности. Но и только. Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу. http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html?
Здравствуйте, Gaperton, Вы писали:
A>>Удивительный вопрос. Из букваря: любая (нестатическая) функция-член эквивалентна просто функции, принимающей первым параметром ссылку на экземпляр класса. Этого довольно?
G>Разумеется не довольно. Работать не будет Пример нарисуй, который я попросил тебя сделать — поймешь.
И не подумаю. На заклинания "Работать не будет" я не реагирую.
Здравствуйте, machine3000, Вы писали:
M>Как то раз чуваки заменили foo(&bar) на bar.foo() и сказали "вот ООП". Другие чуваки посмотрели ассемблерный листинг и сказали "ерунда", это абсолюдно одно и тоже. Вот если написать "virtual foo()" — это ООП. Третьи чуваки возразили, но полиморфизм можно реализовать и вручную другими способами, так что не важно как и что писать, главное чтоб был полиморфизм. Но нашлись и четвёртые. Они стали утверждать что далеко не всякий полиморфизм объектно-ориентированный и принялись смаковать тонкости полиморфизма... M>А как-то раз собравшись все вместе они решили выяснить, объектно-ориентированна ли STL.
ООП на роль серебренной пули конечно не претендует, но говорить что _вообще_ ничего полезного в нем нет как-то странно.
Не буду приводить определения ООП (надо искать, да и без меня тут это сделали) но пару коментариев добавить хочется.
1) В то время как (а может и раньше) одни чуваки заменили foo(&bar) на bar.foo(), другие чуваки сказали, что bar.foo() означает посылку сообщения foo объекту bar, а кроме того придумали, что обработчик для этого сообщения надо искать в объекте bar, а если там нет то, в другом и так далее по цепочке (заметьте ни слова про наследование), а еще эта цепочка может меняться в процессе выполнения.
Мораль: не надо сводить bar.foo() к простому фунциональному (или более сложному через указатель) вызову foo(&bar), есть и другие модели. Можно интереса ради почитать про такой язык как Self
2) Для меня одним из основных преимуществ ООП является разделение ответственности — есть объект и его инрефейс, так вот за все происходящее с самим собой отвечает сам объект и дергать его можно только за его интерфейс и никто внутрь к нему не лезет. Так вот в ООП все это можно определить явно, сказать за что можно ручками дергать, а за что нельзя.
А если все самому делать, то еще надо рядом коментарии писать, что вот эта струкутра — это на самом деле объект, поэтому пожалуйста данные сами не трогайте, а только с помощью определенных функции, а то все работать перестанет. Или что вот тут у нас есть указатели на функции так вот и тоже лучше не менять как попало.
Вроде тоже получается, но как-то больше места для злоупотребления, может даже и для случайного или по глупости
Здравствуйте, RailRoadMan, Вы писали:
RRM>2) Для меня одним из основных преимуществ ООП является разделение ответственности — есть объект и его инрефейс, так вот за все происходящее с самим собой отвечает сам объект и дергать его можно только за его интерфейс и никто внутрь к нему не лезет. Так вот в ООП все это можно определить явно, сказать за что можно ручками дергать, а за что нельзя. RRM>А если все самому делать, то еще надо рядом коментарии писать, что вот эта струкутра — это на самом деле объект, поэтому пожалуйста данные сами не трогайте, а только с помощью определенных функции, а то все работать перестанет. Или что вот тут у нас есть указатели на функции так вот и тоже лучше не менять как попало.
Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
Простыню твоего кода и "объяснения" я скипнул — проблема у тебя спрятана в одной маленькой строчке.
A>template <typename Ti>typename Ti next (typename Ti state){ return ++state; }
В этом примере у тебя итератор — объект с инкапсулированным состоянием и методом ++. Поэтому у тебя волшебным образом и все получилось. Может хватит уже дурку гнать, а? Простыня кода, которую ты привел, не показывает ничего. Главное здесь — определение типа итератора, которое ты не привел. Там у тебя в этот раз вся лажа и спрятана — итератор у тебя полноценный класс. И все, главное, с такими недецкими понтами — умора. И Хаскель-то мы знаем, и собеседник-то идиот . Надоело уже, право.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Gaperton, Вы писали:
A>>>Если Вам не знаком термин "overloading" — на этот счет есть даже целая теория. В контексте HM(X)
G>>Причем здесь хиндли-милнер? Я не понинимаю ваши посты — они мне кажутся начисто лишенными смысла — потоком сознания каким-то.
RRM>awson во много апеллирует в Haskell, я не спец, но немного на него посмотрел. Так вот простите за такое сравнение: реализация классов в Haskell в каком-то смысле схожа с шаблонами в С++
RRM>Вот Gaperton и awson похоже спорят про одно и тоже, но Gapeton со стороны С++ смотрит, а awson со стороны Haskell
Я не понимаю, как можно аппелировать к Хаскелю доказывая тезис, что STL не объектная библиотека. Причем тут Хаскель? Я вообще не понимаю, что за поток сознания идет в постах awson. Он никак не связан с моими постами, я не понимаю, с чем он спорит, и я не понимаю его вопросов (вряд ли он сам их понимает).
Во вторых — на что я смотрю со стороны С++? Почему я смотрю со стороны С++? Вы вообще о чем говорите? Я в этой ветке "смотрю со стороны" классических определений ООП и теории типа. Мне там за них баллы поставили — посмотрите, легко найти.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, WFrag, Вы писали:
WF>>И что из этого? Объекты перестают быть объектами? o_O S>В общем-то да. Теоретически, никто не запрещает этому "объекту" быть просто парой функций current и next.
Это не "чистые" функции. Они апеллируют к некоторому состоянию, являясь интерфейсом его итерирования. Вот это и задаст объект (не итератор, а собственно контейнер). STL — не чистое ФП, потому что контейнеры по дизайну представляют собой объекты с состоянием. В чистом ФП список или дерево — просто набор вызовов разных конструкторов (для списка, скажем, Nil, Cons что-то, Cons что-то, ...), а итерирование идёт через паттерн матчинг по видам конструкторов и рекурсию. При таком итерировании происходит обратный разбор и возможна дефорестация при компиляции: то есть список, как объект в памяти, может вообще не создаваться.
Здравствуйте, StevenIvanov, Вы писали:
SI>Здравствуйте, igna, Вы писали:
I>>Является ли STL объектно-ориентированной библиотекой?
SI>Хотелось бы узнать — каков критерий "объектно-ориентированности"? SI>Раз используются объекты — почему нет? SI>Или обязательны жуткие иерархии наследования?
S>>Так, например, широкое использование функторов является как раз эмуляцией ФП на ООП.
MS>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
Здравствуйте, Left2, Вы писали:
MS>>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
L>Согласная я!!! Даёшь меанизм замыканий в С++!!!
Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что надо было включать в 1999.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Left2, Вы писали:
MS>>>Вот это-то в C++ и убивает. Функторы это, конечно хороший механизм, но определять их приходится не "по месту", а черте где — вне функций, а чаще всего в классах. В результате получается каша.
L>>Согласная я!!! Даёшь меанизм замыканий в С++!!!
M>Ага. Размечталась. Комитет в 2009 собирается включить в язык то, что надо было включать в 1999.
Здравствуйте, Gaperton, Вы писали:
G>Объекты — никакая не вынужденная мера. Без использования объектов никакого STL бы в помине не получилось.
Вот точка зрения основного автора STL на отличие того, чем он занимается, от ООП:
What is the relationship between generic programming and object-oriented programming?
In one sense, generic programming is a natural continuation of the fundamental ideas of object-oriented programming---separating the interface and implementation and polymorphic behavior of the components. However, there is a radical difference. Object-oriented programming emphasizes the syntax of linguistic elements of the program construction. You have to use inheritance, you have to use classes, you have to use objects, objects send messages. Generic programming does not start with the notion of whether you use inheritance or you don't use inheritance. It starts with an attempt to classify or produce a taxonomy of what kinds of things are there and how they behave. That is, what does it mean that two things are equal? What is the right way to define equality? Not just actions of equality. You can analyze equality deeper and discover that there is a generic notion of equality wherein two objects are equal if their parts, or at least their essential parts are equal. We can have a generic recipe for an equality operation. We can discuss what kinds of objects there are. There are sequences. There are operations on sequences. What are the semantics of these operations? What types of sequences from the point of view of complexity tradeoffs should we offer the user? What kinds of algorithms are there on sequences? What kind of different sorting functions do we need? And only after we develop that, after we have the conceptual taxonomy of the components, do we address the issue of how to implement them. Do we use templates? Do we use inheritance? Do we use macros? What kind of language technology do we use? The fundamental idea of generic programming is to classify abstract software components and their behavior and come up with a standard taxonomy. The starting point is with real, efficient algorithms and data structures and not with the language. Of course, it is always embodied in the language. You cannot have generic programming outside of a language. STL is done in C++. You could implement it in Ada. You could implement it in other languages. They would be slightly different, but there are some fundamental things that would be there. Binary search has to be everywhere. Sort has to be everywhere. That's what people do. There will be some modification on the semantics of the containers, slight modifications imposed by the language. In some languages you can use inheritance more, in some languages you have to use templates. But the fundamental difference is precisely that generic programming starts with semantics and semantic decomposition. For example, we decide that we need a component called swap. Then we figure out how this particular component will work in different languages. The emphasis is on the semantics and semantic classification, while object-orientedness, especially as it has evolved, places a much stronger emphasis, and, I think, too much of an emphasis, on precisely how to develop things, that is, using class hierarchies. OOP tells you how to build class hierarchies, but it doesn't tell you what should be inside those class hierarchies.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП.
Не бывает экспертов в ООП или там в метапрограммировании. Бывают эксперты просто в программировании. А если человек начинает разбираться где ООП, а где нет — он скорее философ.
Здравствуйте, machine3000, Вы писали:
G>>Мне знакома его точка зрения. При этом, общеизвестно также, что он не является экспертом в ООП.
M>Не бывает экспертов в ООП или там в метапрограммировании. Бывают эксперты просто в программировании. А если человек начинает разбираться где ООП, а где нет — он скорее философ.
Хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП, а где нет. Но не обязательно. Умение делать классные штуки гораздо важнее.
Но это не означает, что если Степанов скажет выпрыгнуть в окно, то надо перевести мозги на позицию "офф" и так и сделать. У хорошего инженера должно быть свое собственное мнение. И он должен уметь его защищать. Это не прерогатива философов.
Здравствуйте, Gaperton, Вы писали:
G>Хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП, а где нет. Но не обязательно. Умение делать классные штуки гораздо важнее.
От того является код ОО или нет в общем случае он лучше не становится. Важно видеть какие приёмы программирования оптимально подходят для решения конкретной задачи и совершенно никакого значения не имеет к каким парадигмам они при этом относятся.
G>Но это не означает, что если Степанов скажет выпрыгнуть в окно, то надо перевести мозги на позицию "офф" и так и сделать. У хорошего инженера должно быть свое собственное мнение. И он должен уметь его защищать. Это не прерогатива философов.
По поводу выпригивания в окно — должно, по поводу парадигм — вопрос спорный. Чем меньше инженер будет спорить, где ООП, а где нет — тем больше времени у него останется на написание кода.
Здравствуйте, Gaperton, Вы писали:
G>В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
Хм, и это несмотря на то, что ты знаешь, что сам Степанов не считает свою STL объектно-ориентированной. Может быть дело в определении, вот например что написал Саттер:
Well, what is object orientation, anyway? Even at this late date, if you ask 10 people, you're likely to get 15 different answers.
Для меня ООП на C++ приблизительно равно использованию слова virtual, хотя конечно и на С можно сэмулировать объектную ориентированность, и напротив на C++ можно писать virtual везде, где позволяет компилятор не пользуясь возможностями, которые этот самый virtual дает, но в целом для меня virtual == OOP, а для тебя скорее всего нет.
Здравствуйте, Gaperton, Вы писали:
G>В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет.
А разве нельзя обойтись абстрактным типом данных?
Здравствуйте, Трурль, Вы писали:
Т>Здравствуйте, Gaperton, Вы писали:
G>>В любом случае ему понадобится способ выставить абстрактный интерфейс и спрятать состояние, т.е. другими словами ему понадобится "объект", хочет он этого, или нет. Т>А разве нельзя обойтись абстрактным типом данных?
Да собственно "объект" = "АТД" + "инкапсулированное состояние"
Это почти одно и то же.
Здравствуйте, igna, Вы писали:
I>Здравствуйте, Gaperton, Вы писали:
G>>В результате, STL демонстрирует редкий случай удачного сочетания парадигм ООП и ФП на микроуровне (моя любимая библиотека, кстати, одна из самых простых и красивых штуковин что я видел). Противопоставлять ее и тому и другому — неправильно.
I>Хм, и это несмотря на то, что ты знаешь, что сам Степанов не считает свою STL объектно-ориентированной. Может быть дело в определении, вот например что написал Саттер:
I>
I>Well, what is object orientation, anyway? Even at this late date, if you ask 10 people, you're likely to get 15 different answers.
I>Для меня ООП на C++ приблизительно равно использованию слова virtual, хотя конечно и на С можно сэмулировать объектную ориентированность, и напротив на C++ можно писать virtual везде, где позволяет компилятор не пользуясь возможностями, которые этот самый virtual дает, но в целом для меня virtual == OOP, а для тебя скорее всего нет.
Думаю, дело именно в определении. В С++ без virtual ООП не получится, однако объект и без virtual функций с наследованием — все равно самый настоящий объект.
Здравствуйте, machine3000, Вы писали:
G>>Хорошему инженеру-программисту вообще-то неплохо уметь разбираться, где ООП, а где нет. Но не обязательно. Умение делать классные штуки гораздо важнее. M>От того является код ОО или нет в общем случае он лучше не становится. Важно видеть какие приёмы программирования оптимально подходят для решения конкретной задачи и совершенно никакого значения не имеет к каким парадигмам они при этом относятся.
Да. Ну и что? Ты это к чему?
G>>Но это не означает, что если Степанов скажет выпрыгнуть в окно, то надо перевести мозги на позицию "офф" и так и сделать. У хорошего инженера должно быть свое собственное мнение. И он должен уметь его защищать. Это не прерогатива философов. M>По поводу выпригивания в окно — должно, по поводу парадигм — вопрос спорный. Чем меньше инженер будет спорить, где ООП, а где нет — тем больше времени у него останется на написание кода.
Инженеру неплохо понимать, как он пишет код, чтобы его код был хорош. А не просто колбасить код — это любой дурак умеет. А в спорах рождается истина. К слову — я вообще перестал понимать, в чем ты меня хочешь убедить. Вроде как ты со мной споришь, нет?
Здравствуйте, Gaperton, Вы писали:
G>Да. Ну и что? Ты это к чему? G>Инженеру неплохо понимать, как он пишет код, чтобы его код был хорош.
Хорош в каком отношении? Это можно измерить по какими-то описанным методикам? Или речь идёт о том, что "Gaperton" должен посмотреть на этот код и, как истиный ценитель ООП, сказать, да он хорош.
G>А не просто колбасить код — это любой дурак умеет.
Хорошо, но если инженер не "просто" колбасит код, а делает это руководствуясь какими-то своими критериями, например как Степанов, и этот код вдруг по мнению "Gaperton" не достаточно объектно-ориентированный, означает ли это, что код плох?
G>А в спорах рождается истина. К слову — я вообще перестал понимать, в чем ты меня хочешь убедить. Вроде как ты со мной споришь, нет?
Я хотел сказать тоже самое, что сказано в цитате, приведённой "igna". Мнения о том, где ООП, а где нет, различаются у разных людей. А раз так, об этом говорить с точки зрения производственного процесса бессмысленно.
К слову, я вашу точку зрения и методы ведения дискуссии хорошо понимаю.
Здравствуйте, Gaperton, Вы писали:
G>... Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу.
Удивительный вопрос. Из букваря: любая (нестатическая) функция-член эквивалентна просто функции, принимающей первым параметром ссылку на экземпляр класса. Этого довольно?
Здравствуйте, awson, Вы писали:
G>>... Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу.
A>Удивительный вопрос. Из букваря: любая (нестатическая) функция-член эквивалентна просто функции, принимающей первым параметром ссылку на экземпляр класса. Этого довольно?
Неа, мы глупые. Так что объясни подробно, с и примерами.
А может быть где-то уже есть реализация всей STL на С++, где все ее элементы не имеют состояния, раз уж теперь это понятно всей прогрессивной общественности?
Здравствуйте, machine3000, Вы писали:
M>Как то раз чуваки заменили foo(&bar) на bar.foo() и сказали "вот ООП". Другие чуваки посмотрели ассемблерный листинг и сказали "ерунда", это абсолюдно одно и тоже. Вот если написать "virtual foo()" — это ООП. Третьи чуваки возразили, но полиморфизм можно реализовать и вручную другими способами, так что не важно как и что писать, главное чтоб был полиморфизм. Но нашлись и четвёртые. Они стали утверждать что далеко не всякий полиморфизм объектно-ориентированный и принялись смаковать тонкости полиморфизма... M>А как-то раз собравшись все вместе они решили выяснить, объектно-ориентированна ли STL.
Мораль, мораль-то какая у басни?
В том, что STL не объектаная, или в том, что необходимо обосрать участников?
Здравствуйте, awson, Вы писали:
G>>Объекты Степанов использует (итераторы, контейнеры). И никуда он от них не денется. Он может не называть объекты объектами — это не меняет суть дела, объекты они объекты и есть — в них завернуто состояние и к нему нет прямого доступа. Самый пренастоящий объект.
A>Ни состояние, ни отсутствие прямого доступа нафик для STL не нужны. То есть вообще. Это сделано только для удобства в контексте C++ *уровня понимания первой половины 90-х*.
Но ведь сделано же? Значит по факту активно используются объекты с состоянием.
А так, если бы у бабушки был член, то она была бы дедушкой.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Объекты Степанов использует (итераторы, контейнеры). И никуда он от них не денется. Он может не называть объекты объектами — это не меняет суть дела, объекты они объекты и есть — в них завернуто состояние и к нему нет прямого доступа. Самый пренастоящий объект.
A>Ни состояние, ни отсутствие прямого доступа нафик для STL не нужны. То есть вообще. Это сделано только для удобства в контексте C++ *уровня понимания первой половины 90-х*. Сейчас хорошо понятно, как написать все то же безо всякого состояния и вообще без потерь эффективности.
Здравствуйте, Андрей Хропов, Вы писали:
АХ>Здравствуйте, Gaperton, Вы писали:
G>>Ну, итераторы, положим, можно сделать stateless без потери эффективности.
АХ>Как? Итератор хранит положение в контейнере.
Да и пусть хранит. Его теоретически возможно сделать на недеструктивных (const) операциях — пусть себе копируется при каждом движении вперед-назад. Он маленький, оверхэд будет невелик. В этом случае можно будет сказать, что у итератора как у объекта нет изменяемого состояния.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>... Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу.
A>Удивительный вопрос. Из букваря: любая (нестатическая) функция-член эквивалентна просто функции, принимающей первым параметром ссылку на экземпляр класса. Этого довольно?
Разумеется не довольно. Работать не будет Пример нарисуй, который я попросил тебя сделать — поймешь.
Здравствуйте, Gaperton, Вы писали:
G>>>Можно. Стоимость внесения изменений в код является весьма неплохой характеристикой качества кода. Ее можно измерить. Вообще — хороший код прежде всего прост для человеческого понимания. M>>Интересная тема. Но если вы разговор продолжать не хотите... G>Ок, если вы меня в третьем лице называть не будете, то продолжим. Тема действительно интересная. Что вы думаете по этому поводу?
Интуиция мне подсказывает, что число существующих точек зрения по этому вопросу того же порядка, что и число точек зрения относительно границ парадигмы ООП.
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
A>>>Удивительный вопрос. Из букваря: любая (нестатическая) функция-член эквивалентна просто функции, принимающей первым параметром ссылку на экземпляр класса. Этого довольно?
G>>Разумеется не довольно. Работать не будет Пример нарисуй, который я попросил тебя сделать — поймешь.
A>И не подумаю. На заклинания "Работать не будет" я не реагирую.
А я не реагирую на заклинания вроде "удивительный вопрос", "из букваря", и "этого довольно". Это, ИМХО, голые понты. Показать не можешь — значит не знаешь.
Работать у тебя не будет потому, что информацию о типе итератора ты теряешь и передать в generic-функцию не сможешь — и, как следствие, не сможешь написать эту обобщенную функцию. Понять это ты сможешь только попробовав написать пример, и обломавшись. В букварях о таких тонкостях не пишут. Не хочешь писать — не пиши, твои заблуждения это твои проблемы, мне-то все равно.
Здравствуйте, palm mute, Вы писали:
PM>Здравствуйте, Gaperton, Вы писали:
G>>Ну, итераторы, положим, можно сделать stateless без потери эффективности. Но и только. Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу. PM>http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html?
На С++, плз. Знаем мы эти ленивые языки — там итераторы не нужны, достаточно в список любой контейнер превратить, вот и все итераторы.
Здравствуйте, Gaperton, Вы писали:
G>>>Ну, итераторы, положим, можно сделать stateless без потери эффективности. Но и только. Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу. PM>>http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html?
G>На С++, плз. Знаем мы эти ленивые языки — там итераторы не нужны, достаточно в список любой контейнер превратить, вот и все итераторы.
А причём тут ленивость языка? В том же scheme, который не ленивый, есть stream.
Здравствуйте, konsoletyper, Вы писали:
K>Здравствуйте, Gaperton, Вы писали:
G>>>>Ну, итераторы, положим, можно сделать stateless без потери эффективности. Но и только. Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе. Короче, не поверю, пока не увижу. PM>>>http://haskell.org/ghc/docs/latest/html/libraries/base/Data-Traversable.html?
G>>На С++, плз. Знаем мы эти ленивые языки — там итераторы не нужны, достаточно в список любой контейнер превратить, вот и все итераторы.
K>А причём тут ленивость языка? В том же scheme, который не ленивый, есть stream.
А причем здесь Схема? Схема строгая и динамическая, и с развитой макросистемой. Там и объекты, и итераторы, и вообще все что захочешь изобразить можно — абсолютно любой выкрутас. На С++ плиз. Я говорю о С++
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, RailRoadMan, Вы писали:
RRM>>2) Для меня одним из основных преимуществ ООП является разделение ответственности — есть объект и его инрефейс, так вот за все происходящее с самим собой отвечает сам объект и дергать его можно только за его интерфейс и никто внутрь к нему не лезет. Так вот в ООП все это можно определить явно, сказать за что можно ручками дергать, а за что нельзя. RRM>>А если все самому делать, то еще надо рядом коментарии писать, что вот эта струкутра — это на самом деле объект, поэтому пожалуйста данные сами не трогайте, а только с помощью определенных функции, а то все работать перестанет. Или что вот тут у нас есть указатели на функции так вот и тоже лучше не менять как попало.
G>Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
Пример если честно мне не очень нравится, потому как for_each — это шаблонная функция, т.е. тут помимо ООП еще и метапрограммирование и статический полиморфизм. И если быть совершенно строгим то for_each не одна, а их сгенерируется по количеству используемых типов итераторов.
G>Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
В этом примере для честности надо бы еще и препроцессор приплести, потому как шаблоны — это крутые макросы
Здравствуйте, RailRoadMan, Вы писали:
RRM>1) В то время как (а может и раньше) одни чуваки заменили foo(&bar) на bar.foo(), другие чуваки сказали, что bar.foo() означает посылку сообщения foo объекту bar, а кроме того придумали, что обработчик для этого сообщения надо искать в объекте bar, а если там нет то, в другом и так далее по цепочке (заметьте ни слова про наследование), а еще эта цепочка может меняться в процессе выполнения. RRM>Мораль: не надо сводить bar.foo() к простому фунциональному (или более сложному через указатель) вызову foo(&bar), есть и другие модели. Можно интереса ради почитать про такой язык как Self
Не, эти чуваки решили, что bar.foo() нужно писать как bar foo, а "if (foo) bar()" как "bar foo ifTrue" или что-то в этом духе. Потом они еще долго гонялись за зайцами чтобы отдать им фотографии (с) Лето в Простоквашино.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>Работать у тебя не будет потому, что информацию о типе итератора ты теряешь и передать в generic-функцию не сможешь — и, как следствие, не сможешь написать эту обобщенную функцию. Понять это ты сможешь только попробовав написать пример, и обломавшись. В букварях о таких тонкостях не пишут. Не хочешь писать — не пиши, твои заблуждения это твои проблемы, мне-то все равно.
В личной переписке я просто не стал бы утруждаться. Но, поскольку это читают другие люди, и им это может быть полезно, извольте:
#include <deque>
#include <vector>
#include <iostream>
using namespace std;
//+++ Функциональные адаптеры для итераторов. Нужны *ТОЛЬКО* для того, чтобы не переписывать STL заново +++template <typename T> typename T::const_iterator begin (const T & container) {return container.begin();}
template <typename T> typename T::const_iterator end (const T & container) {return container.end();}
template <typename T> typename T::const_iterator next (const T & type_selector, typename T::const_iterator state) {return state + 1;}
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++template <typename T> void print_elem(const T & type_selector, typename T::const_iterator end, typename T::const_iterator state)
{
if (state != end)
{
cout << *state << endl;
print_elem(type_selector, end, next(type_selector, state));
}
}
template <typename T> void print_container(const T & cnt)
{
typename T::const_iterator b = begin(cnt);
typename T::const_iterator e = end(cnt);
print_elem(cnt, e, b);
}
int main()
{
deque<int> m;
m.push_back(20);
m.push_back(30);
m.push_back(10);
cout << "print_deque" << endl;
print_container(m);
vector<int> v;
v.push_back(20);
v.push_back(30);
v.push_back(10);
cout << "print_vector" << endl;
print_container(v);
}
В качестве альтернативного вектору контейнера выбран deque, поскольку map — в том виде как он реализован в STL сейчас — не имеет недеструктивного инкремента итераторов. Переписывать STL я не намерен, поэтому жуйте что дают и скажите спасибо за науку.
Здравствуйте, Gaperton, Вы писали:
G>Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
G>Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
Вы путаете теплое с мягким. Выше я Вам уже ответил
Но я ведь спросил, объектно-ориентированна ли STL, и поскольку она написана на C++, то не может быть объектно-ориентированной без virtual, так?
Использование объектов IMHO необходимо, но недостаточно для ООП. Вроде ты тоже так думаешь:
G>... В С++ без virtual ООП не получится, однако объект и без virtual функций с наследованием — все равно самый настоящий объект.
Здравствуйте, RailRoadMan, Вы писали:
G>>Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
RRM>Пример если честно мне не очень нравится, потому как for_each — это шаблонная функция, т.е. тут помимо ООП еще и метапрограммирование и статический полиморфизм. И если быть совершенно строгим то for_each не одна, а их сгенерируется по количеству используемых типов итераторов.
Это неважно — это абсолютно ничего не значащие для нашей ситуации детали. Представьте, что у нас не С++, а JavaScript. Код останется таким же, только for_each будет самой обыкновенной, а не шаблонной функцией, а полиморфизм будет динамическим (JavaScript динамический язык).
Кстати, for_each не имеет никакого отношения к метапрограммированию — это обыкновенная полиморфная функция. И совершенно неважно, сколько именно и какого кода сгенерирует компилятор для for_each — это вообще проблемы компилятора, он их может решать по всякому.
G>>Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
RRM>В этом примере для честности надо бы еще и препроцессор приплести, потому как шаблоны — это крутые макросы
Я согласен с тобой, просто мне кажется, что когда Степанов говрил, что STL построена не на ООП, он имел в виду "классический ООП раньнего периода С++", того ктр построен на наследовании и виртуальных функциях, и ктр какое-то время и считался ООП (для С++ по крайне мере). Так вот такого ООП в STL нет, тут степанов прав, просто он именно таким в тот момент считал ООП в С++. Но это исключительно ИМХО
G>>>Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
RRM>>В этом примере для честности надо бы еще и препроцессор приплести, потому как шаблоны — это крутые макросы
G>В этом примере нет ничего лишнего.
Я имел в виду, что если делать for_each на голом С, то вместо темплейтов препроцессор приделуть, но в общем не будем придавать значения моей шутке
Здравствуйте, RailRoadMan, Вы писали:
RRM>Я согласен с тобой, просто мне кажется, что когда Степанов говрил, что STL построена не на ООП, он имел в виду "классический ООП раньнего периода С++", того ктр построен на наследовании и виртуальных функциях, и ктр какое-то время и считался ООП (для С++ по крайне мере). Так вот такого ООП в STL нет, тут степанов прав, просто он именно таким в тот момент считал ООП в С++. Но это исключительно ИМХО
Степанов претендовал на изобретение новой парадигмы — "generic programming". И я его всецело поддерживаю в этом вопросе. Однако, следует учитывать мнение других людей, которые рассудили так: "Что, новая парадигма? Мы что, не в той парадигме всю жизнь работали? Да не какая это не новая парадигма. Всё это уже было. Вот ООП, вот ФП, а всё остальное — детали."
Здравствуйте, awson, Вы писали:
A> Переписывать STL я не намерен, поэтому жуйте что дают и скажите спасибо за науку.
1) Обойдешься без спасибо — хамам спасибо не говорят. Таким как ты я вообще не отвечаю обычно, но только потому, что тебя читают другие люди — отвечу.
2) Лажу всякую, в надежде что народ схавает, подсовывать не надо. Тебе в каждый стандартный алгоритм и в каждую функцию, работающую с итераторами контейнер придется передавать (как я тебе и говорил — тип контейнера у тебя теряется по дороге, а тип тебе надо как-то передавать). Выглядеть у тебя в результате типичный вызов for_each будет так:
for_each( my_container, begin( my_contaiuner ), end( my_container ), fun ).
И вообще все функции, работающие с итераторами, должны получить контейнер, так что весь код будет написан через задний проход на ровном месте. Что, конечно, очень прогрессивно, и в сто раз круче, чем по старинке
for_each( my_container.begin(), my_container.end(), fun ).
потому что ООП — это отстой, и пережиток начала 90-х.
3) Как ты собрался функторы без объектов делать? А, понятно — опишешь структурку с состоянием и перегруженную функцию двух аргументов functor рядом. Которая будет выглядеть, как функция двух аргументов — состояние + собственно аргумент. В результате, тебе придется делать по две реализации несчастного for_each и прочих алгоритмов (для функций и функуторов). Но это ничего, сойдет — главное, что без объектов — ООП то у нас говно.
4) А вот за отсутствие такого пережитка 90-х, как деструкторов, в такой библиотеке, как STL, тебя бы программеры просто линчевали на месте. Тут даже комментировать не буду. А деструкторы низя — если нет объектов — так обходись структурами.
Это только те косяки, которые лежат на поверхности — я их заметил сразу. А там чем дальше в лес — тем больше дров.
Здравствуйте, RailRoadMan, Вы писали:
RRM>Здравствуйте, Gaperton, Вы писали:
RRM>Я согласен с тобой, просто мне кажется, что когда Степанов говрил, что STL построена не на ООП, он имел в виду "классический ООП раньнего периода С++", того ктр построен на наследовании и виртуальных функциях, и ктр какое-то время и считался ООП (для С++ по крайне мере). Так вот такого ООП в STL нет, тут степанов прав, просто он именно таким в тот момент считал ООП в С++. Но это исключительно ИМХО
Согласен. Очевидно, Степанов имел под "ООП" в виду классы С++ с виртуальными функциями.
Здравствуйте, machine3000, Вы писали:
RRM>>Я согласен с тобой, просто мне кажется, что когда Степанов говрил, что STL построена не на ООП, он имел в виду "классический ООП раньнего периода С++", того ктр построен на наследовании и виртуальных функциях, и ктр какое-то время и считался ООП (для С++ по крайне мере). Так вот такого ООП в STL нет, тут степанов прав, просто он именно таким в тот момент считал ООП в С++. Но это исключительно ИМХО
M>Степанов претендовал на изобретение новой парадигмы — "generic programming". И я его всецело поддерживаю в этом вопросе. Однако, следует учитывать мнение других людей, которые рассудили так: "Что, новая парадигма? Мы что, не в той парадигме всю жизнь работали? Да не какая это не новая парадигма. Всё это уже было. Вот ООП, вот ФП, а всё остальное — детали."
Ну да. Крутую штуку Степанов придумал — в С++ на шаблонах и классах ФВП с замыканиями изображать. Для кого-то, неверное, новая парадигма. А вот тут есть еще круче парадигма — LISP на C++.
Здравствуйте, Gaperton, Вы писали:
G>1) Обойдешься без спасибо — хамам спасибо не говорят. Таким как ты я вообще не отвечаю обычно, но только потому, что тебя читают другие люди — отвечу.
Я все думал, хватит ли у тебя ума остыть и не позориться. Ну, ты сам все сделал, так что приступим:
G>2) Лажу всякую, в надежде что народ схавает, подсовывать не надо. Тебе в каждый стандартный алгоритм и в каждую функцию, работающую с итераторами контейнер придется передавать (как я тебе и говорил — тип контейнера у тебя теряется по дороге, а тип тебе надо как-то передавать). Выглядеть у тебя в результате типичный вызов for_each будет так:
G>for_each( my_container, begin( my_contaiuner ), end( my_container ), fun ).
G>И вообще все функции, работающие с итераторами, должны получить контейнер, так что весь код будет написан через задний проход на ровном месте. Что, конечно, очень прогрессивно, и в сто раз круче, чем по старинке
G>for_each( my_container.begin(), my_container.end(), fun ).
Ты фундаментально не понимаешь одного простого факта — структурно для алгоритма контейнер *это и есть итератор*. Что и как физически хранится — совершенно несущественно. Вот ты докопался до мелочей, типа, "косяки" нашел. Можешь помедитировать на это (я заодно, так и быть, сделал тебе map — пришлось деструктивным итератором эмулировать):
#include <map>
#include <vector>
#include <iostream>
using namespace std;
//+++ Функциональные адаптеры для итераторов. Нужны *ТОЛЬКО* для того, чтобы не переписывать STL заново +++
template <typename T> typename T::const_iterator begin (const T & container) {return container.begin();}
template <typename T> typename T::const_iterator end (const T & container) {return container.end();}
template <typename Ti>typename Ti next (typename Ti state){ return ++state; }
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
//+++ Еще нужно уметь печатать пары
template <typename a, typename b>
ostream & operator << (ostream &os, pair<a, b> const &p)
{
return os << p.first << '=' << p.second;
}
//+++++++++++++++++++++++++++++++++
template <typename Ti> void print_elem(typename Ti end, typename Ti state)
{
if (state != end)
{
cout << *state << endl;
print_elem(end, next(state));
}
}
template <typename T> void print_container(const T & cnt)
{
print_elem(end(cnt), begin(cnt));
}
int main()
{
map<int,int> m;
m.insert(pair<int,int>(3,20));
m.insert(pair<int,int>(2,30));
m.insert(pair<int,int>(1,10));
cout << "print_map" << endl;
print_container(m);
vector<int> v;
v.push_back(20);
v.push_back(30);
v.push_back(10);
cout << "print_vector" << endl;
print_container(v);
}
Химически чистый фолд (print_elem), эксплицитный тип контейнера не нужен.
G>3) Как ты собрался функторы без объектов делать? А, понятно — опишешь структурку с состоянием и перегруженную функцию двух аргументов functor рядом. Которая будет выглядеть, как функция двух аргументов — состояние + собственно аргумент. В результате, тебе придется делать по две реализации несчастного for_each и прочих алгоритмов (для функций и функуторов). Но это ничего, сойдет — главное, что без объектов — ООП то у нас говно.
Ты, помнится, Хаскелл ругал. Рекомендую заняться. Через годик много чего поймешь и С++ в том числе.
G>4) А вот за отсутствие такого пережитка 90-х, как деструкторов, в такой библиотеке, как STL, тебя бы программеры просто линчевали на месте. Тут даже комментировать не буду. А деструкторы низя — если нет объектов — так обходись структурами.
Это: G>"Насчет прямого доступа к данным объекта — я посмотрю как вы не завернув итератор в объект с абстрактным интерфейсом сформулируете алгоритм, работаюший как на контейнере "map" (дерево), так и на векторе." G>"Работать не будет Пример нарисуй, который я попросил тебя сделать — поймешь."
кто писал?
Сформулировал, как видишь в 3-х строчках. И работает. Ты пытаешься поднять шум и свалить из темы пока никто ничего не понял. Начал с анекдотических наездов на Степанова, закончил деструкторами.
Здравствуйте, Gaperton, Вы писали:
G>Вся суть объектности (ну, ок, половина сути) в этой связи — объект знает свой тип, он сам решает, как ему обрабатывать "сообщение". При попытке эмулировать объекты "на функциях" эта связь теряется, и описать полиморфную функцию for_each работающую с произвольным контейнером становится невозможно. Без дикого изврата с полной фактической эмуляцией объектов на С, как это делали в конце 80-х и начале 90-х. Что, безусловно, очень "прогрессивно" — ведь ООП у нас "морально устарел" .
Долго думал над этой фразой. Все-таки мне непонятно, что мешает сделать полиморфную функцию iter_advance, которая принимает на входе итератор, и использовать ее в for_each вместо ++?
Почитал тред дальше — он заметно вырос пока я писал. Поэтому для ясности процитирую и вот эту фразу.
G>Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
Но ведь и в первом случае компилятор знает о типе объекта и он точно так же может связать тип итератора с правильной реализацией iter_advance. Т.е. запись x.foo() это всего-лишь синтаксический сахар, не более.
awson wrote:
> template <typename T> typename T::const_iterator next (const T & type_selector, typename T::const_iterator state) {return state + 1;}
По-моему фигня какая-то. Ту проблему, которую вы пытаетесь решить, давно уже в boost::range решили. Или я что-то не догоняю?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ., Вы писали:
.>awson wrote:
>> template <typename T> typename T::const_iterator next (const T & type_selector, typename T::const_iterator state) {return state + 1;} .>По-моему фигня какая-то. Ту проблему, которую вы пытаетесь решить, давно уже в boost::range решили. Или я что-то не догоняю?
Я не пытаюсь решать никаких проблем. Это *иллюстрация* как все выглядит "без объектов". Причем здесь Boost?
написал все без него. Поскольку в последнее время я пишу в основном на Хаскелле, первый вариант я написал автоматически — там это идиома, когда нужно "получить доступ к словарю" (я не буду пояснять, что это значит). Однако, как я продемонстрировал, это *элементарно* переделывается в вариант если параметром шаблона сделать тип итератора. Кстати, если нужен тип контейнера — по дизайну STL итератор его отдает. Это потому что STL, к счастию, делал "не эксперт в ООП"
awson wrote:
>> > template <typename T> typename T::const_iterator next (const T & > type_selector, typename T::const_iterator state) {return state + 1;} > .>По-моему фигня какая-то. Ту проблему, которую вы пытаетесь решить, > давно уже в boost::range решили. Или я что-то не догоняю? > > Я не пытаюсь решать никаких проблем. Это *иллюстрация* как все выглядит > "без объектов". Причем здесь Boost? > > Этот кусок вообще чисто технический. > > Если вам не нравится type_selector, я буквально рядом > <http://rsdn.ru/Forum/Message.aspx?mid=2499473&only=1>
написал все без > него. Поскольку в последнее время я пишу в основном на Хаскелле, первый > вариант я написал автоматически — там это идиома, когда нужно "получить > доступ к словарю" (я не буду пояснять, что это значит). Однако, как я > продемонстрировал, это *элементарно* переделывается в вариант если > параметром шаблона сделать тип итератора. Кстати, если нужен тип > контейнера — по дизайну STL итератор его отдает. Это потому что STL, к > счастию, делал "не эксперт в ООП"
Просто до сих пор понять не могу, чем это отличается от "чистого" STL. Дофига методов в stl берут <typename Ti>, только
называют это дело обычно <typename Iter>. Два отличия — свободные ф-ции begin/end (ну и что что в С++ можно превратить
obj.method() в method(obj) ), которые есть в boost::range. И print_elem перебирает не в привычном для C++ цикле for,
а рекурсивной ф-цией. В общем всё. Причём тут ООПшность?
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, COFF, Вы писали:
COF>Почитал тред дальше — он заметно вырос пока я писал. Поэтому для ясности процитирую и вот эту фразу.
G>>Все так. Тока есть еще одно, более важное отличие интерфейса объекта, реализованного на соглашениях (foo(&x)), от объекта, поддерживаемого языком (x.foo()). Разница в том, что во втором случае компилятор знает о типе объекта, и в состоянии правильно отдиспетчеризовать вызов foo. Пример из STL. Алгоритм for_each. В реализация for_each полагается на наличие у аргументов-итераторов метода (оператора) ++. Однако, если мы вызовем for_each на итераторах вектора и мапа, будут вызваны разные операторы ++. При этом, реализация for_each одна и та же. Возможно это потому, что компилятор связывает тип итератора с правильной реализацией ++.
COF>Но ведь и в первом случае компилятор знает о типе объекта и он точно так же может связать тип итератора с правильной реализацией iter_advance. COF>Т.е. запись x.foo() это всего-лишь синтаксический сахар, не более.
Попробуй написать сигнатуры этих двух реализаций функиий iter_advance, для map-а и vector-a. Учитывая, что vector< int >::iterator и vector< double >::iterator — это, по хорошему, должны быть разные типы. Я не знаю, как то сделать. Может, и можно — темплейтовые метапрограммисты чрезвычайно изобретательны, за ними не поспеть.
Так вот — если бы это было можно сделать — то все равно у тебя получился бы самый настоящий объект (ну, с оговоркой — в динамике вызов не диспетчеризуется, но в приведенном примере этого и не требуется), хоть и без применения внутренних методов. Дело ведь не в том, как писать — x.foo() или foo( x ), и писать ли слово class. Не то делает объект объектом. В некоторых языках вообще классов нет — а они объектные. Дело в том, что компилятор знает о связи типа х и конкретной реализацией foo.
О том и речь — без объектов не получится никакого STL.
Здравствуйте, Gaperton, Вы писали:
G>В этом примере у тебя итератор — объект с инкапсулированным состоянием и методом ++. Поэтому у тебя волшебным образом и все получилось. Может хватит уже дурку гнать, а? Простыня кода, которую ты привел, не показывает ничего. Главное здесь — определение типа итератора, которое ты не привел. Там у тебя в этот раз вся лажа и спрятана — итератор у тебя полноценный класс. И все, главное, с такими недецкими понтами — умора. И Хаскель-то мы знаем, и собеседник-то идиот . Надоело уже, право.
, что для первого примера не выбрал map только потому, что у его итератора нет недеструктивного инкремента (его легко сделать если залезть внутрь STL). "Простыню" я привожу только для того, чтобы ты мог убедиться, что все работает. Я не знаю, что ты выдумаешь на этот раз, но пожалуйста — примите и распишитесь:
#include <deque>
#include <vector>
#include <iostream>
using namespace std;
//+++ Функциональные адаптеры для итераторов. Нужны *ТОЛЬКО* для того, чтобы не переписывать STL заново +++template <typename T> typename T::const_iterator begin (const T & container) {return container.begin();}
template <typename T> typename T::const_iterator end (const T & container) {return container.end();}
template <typename Ti>typename Ti next (typename Ti state){ return state+1; }
//++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++template <typename Ti> void print_elem(typename Ti end, typename Ti state)
{
if (state != end)
{
cout << *state << endl;
print_elem(end, next(state));
}
}
template <typename T> void print_container(const T & cnt)
{
print_elem(end(cnt), begin(cnt));
}
int main()
{
deque<int> m;
m.push_back(20);
m.push_back(30);
m.push_back(10);
cout << "print_map" << endl;
print_container(m);
vector<int> v;
v.push_back(20);
v.push_back(30);
v.push_back(10);
cout << "print_vector" << endl;
print_container(v);
}
Здравствуйте, awson, Вы писали:
G>>1) Обойдешься без спасибо — хамам спасибо не говорят. Таким как ты я вообще не отвечаю обычно, но только потому, что тебя читают другие люди — отвечу.
A>Я все думал, хватит ли у тебя ума остыть и не позориться. Ну, ты сам все сделал, так что приступим:
Неудобную проблемку с функтором, которая вынуждает тебя делать по две реализации generic-функций, ты, кстати, пропустил. Не удивительно. Я, собственно, ничего другого и не ожидал.
Здравствуйте, ., Вы писали: .>а рекурсивной ф-цией. В общем всё. Причём тут ООПшность?
Дак в том и дело что не причем. Я как раз об этом и говорю. Что никакого "синтеза ООП и ФП" парадигм в STL нет. Что STL — никоим боком НЕ ООП библиотека. У этого Gaperton'а семь пятниц на неделе. То он про состояние толковал, то про инкапсуляцию методов в класс, то вообще деструкторами закончил.
Здравствуйте, Gaperton, Вы писали:
G>Попробуй написать сигнатуры этих двух реализаций функиий iter_advance, для map-а и vector-a. Учитывая, что vector< int >::iterator и vector< double >::iterator — это, по хорошему, должны быть разные типы. Я не знаю, как то сделать. Может, и можно — темплейтовые метапрограммисты чрезвычайно изобретательны, за ними не поспеть.
Это сделать элементарно. И чтобы это были разные типы. Но дело не в этом. Дело в том, что это НЕ должны быть разные типы, хотя и могут ими быть. Если Вы не используете overloading (ad hoc полиморфизм, см. ниже), Вам не нужно знать какого типа элементы в контейнере. Например (самый тривиальный), Вам не нужно знать, какого типа элементы в контейнере, чтобы посчитать их количество. Это называется true полиморфизм.
G>Так вот — если бы это было можно сделать — то все равно у тебя получился бы самый настоящий объект (ну, с оговоркой — в динамике вызов не диспетчеризуется, но в приведенном примере этого и не требуется), хоть и без применения внутренних методов. Дело ведь не в том, как писать — x.foo() или foo( x ), и писать ли слово class. Не то делает объект объектом. В некоторых языках вообще классов нет — а они объектные. Дело в том, что компилятор знает о связи типа х и конкретной реализацией foo.
Ключевые слова здесь — "конкретной реализацией". И это называется не ОО, а называется overloading. Вы дико удивитесь, но от ОО оно вообще никак не зависит. Если Вы, конечно, в очередной раз (до этого были: состояние, инкапсуляция, деструкторы) не объявите, что ОО — это как раз overloading.
awson wrote:
> .>а рекурсивной ф-цией. В общем всё. Причём тут ООПшность? > Дак в том и дело что не причем. Я как раз об этом и говорю. Что никакого > "синтеза ООП и ФП" парадигм в STL нет. Что STL — никоим боком *НЕ* ООП > библиотека. У этого Gaperton'а семь пятниц на неделе. То он про > состояние толковал, то про инкапсуляцию методов в класс, то вообще > деструкторами закончил.
Вообще говоря, ООП можно углядеть в структурах/классах, а ФП в шаблонах и вычисление типов, то синтез таки есть.
Можно итератор (или контейнер) рассматривать как объект, а его тип (который по сути нужен только для обнаружения ошибок
на этапе компиляции) вычисляется ФП. Т.е. ООП — во время исполнения, а ФП — во время компиляции. Превращение
obj.method() в method(obj) не вынуждает отказываться от рассмотрения кода с т.з. ООП.
И, вообще говоря, можно считать, что это парадигма языка С++, а не stl конкретно.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
G>Это только те косяки, которые лежат на поверхности — я их заметил сразу. А там чем дальше в лес — тем больше дров.
не хотелось влезать.
но интересно, что думаешь о mpl (compile-time аналог stl)
Здравствуйте, ., Вы писали:
.>В смысле? rsdn позволяет только один...
rsdn не располагает технологиями идентификации личности по тексту высказываний. У вас profile как две капли воды похож на profile другого участника форума. Возможно, это просто редкое совпадение.
Здравствуйте, awson, Вы писали:
WF>>Оператор "+" такой же метод объекта итератора, как и "++". Работающий с состоянием итератора.
A>Он это состояние не изменяет (объявлен как const) и возвращает новый итератор.
И что из этого? Объекты перестают быть объектами? o_O
machine3000 wrote:
> .>В смысле? rsdn позволяет только один... > rsdn не располагает технологиями идентификации личности по тексту > высказываний. У вас profile как две капли воды похож на profile другого > участника форума. Возможно, это просто редкое совпадение.
На чей? Мой тут.
Больше я не регистрировался.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>Попробуй написать сигнатуры этих двух реализаций функиий iter_advance, для map-а и vector-a. Учитывая, что vector< int >::iterator и vector< double >::iterator — это, по хорошему, должны быть разные типы. Я не знаю, как то сделать. Может, и можно — темплейтовые метапрограммисты чрезвычайно изобретательны, за ними не поспеть.
A>Это сделать элементарно. И чтобы это были разные типы. Но дело не в этом. Дело в том, что это НЕ должны быть разные типы, хотя и могут ими быть. Если Вы не используете overloading (ad hoc полиморфизм, см. ниже), Вам не нужно знать какого типа элементы в контейнере. Например (самый тривиальный), Вам не нужно знать, какого типа элементы в контейнере, чтобы посчитать их количество. Это называется true полиморфизм.
не true полиморфизм, а параметрический полиморфизм. Это во-первых. Во-вторых — это должны быть разные типы. Хотя бы потому, что *iterator имеет для них разный тип. В третьих — меня совершенно не интересует, "элементарно" или "не элементарно" это делается по твоему мнению. Элементарно — покажи.
G>>Так вот — если бы это было можно сделать — то все равно у тебя получился бы самый настоящий объект (ну, с оговоркой — в динамике вызов не диспетчеризуется, но в приведенном примере этого и не требуется), хоть и без применения внутренних методов. Дело ведь не в том, как писать — x.foo() или foo( x ), и писать ли слово class. Не то делает объект объектом. В некоторых языках вообще классов нет — а они объектные. Дело в том, что компилятор знает о связи типа х и конкретной реализацией foo.
A>Ключевые слова здесь — "конкретной реализацией". И это называется не ОО, а называется overloading.
Что называется ОО — сказано в определении ОО, я его приводил. А "это" называется не overloading, а "ad-hoc полиморфизм", и является один из атрибутов ОО.
A>Вы дико удивитесь, ...
Не удивлюсь, не переживайте.
Здравствуйте, machine3000, Вы писали:
M>Всё считать статистика по всем участникам форума нужна. Но, на вскидку, три девятки тут получится
Детектив, понимаешь.
Хинт: личные данные в профиле можно редактировать. А в заголовках сообщений остается тот ник, который был на момент написания сообщения. Можно посмотреть историю сообщений (или избранные — их таки меньше) и увидеть разные ники здесь
. wrote: >> rsdn не располагает технологиями идентификации личности по тексту >> высказываний. У вас profile как две капли воды похож на profile другого >> участника форума. Возможно, это просто редкое совпадение. > На чей? Мой тут <http://rsdn.ru/Users/Profile.aspx?uid=20380>. > Больше я не регистрировался.
Нефиг было ник менять
Здравствуйте, awson, Вы писали:
A>Здравствуйте, ., Вы писали: .>>а рекурсивной ф-цией. В общем всё. Причём тут ООПшность?
A>Дак в том и дело что не причем. Я как раз об этом и говорю. Что никакого "синтеза ООП и ФП" парадигм в STL нет. Что STL — никоим боком НЕ ООП библиотека. У этого Gaperton'а семь пятниц на неделе. То он про состояние толковал, то про инкапсуляцию методов в класс, то вообще деструкторами закончил.
Твоя точка зрения понятна. Из того, что ты в десятке постов грозишься переписать STL через задний проход, неопровержимо следует, что STL не объектная библиотека.
Здравствуйте, ., Вы писали:
.>Можно итератор (или контейнер) рассматривать как объект, а его тип (который по сути нужен только для обнаружения ошибок .>на этапе компиляции) вычисляется ФП. Т.е. ООП — во время исполнения, а ФП — во время компиляции.
Ну, если быть точным — ФП там — это функторы (это симуляция замыканий — closures), и "алгоритмы" (функции высокого порядка — принимающие аргументами другие функции и функкторы-замыкания).
Здравствуйте, Gaperton, Вы писали:
G>Во-вторых — это должны быть разные типы. Хотя бы потому, что *iterator имеет для них разный тип.
G>А "это" называется не overloading, а "ad-hoc полиморфизм", и является один из атрибутов ОО.
Вы читать умеете?
Я же прямо написал: "Если Вы не используете overloading (ad hoc полиморфизм, см. ниже), Вам не нужно знать какого типа элементы в контейнере."
*Зачем* Вам тип *iterator, если у Вас нет overloading? Т.е., если нет, цитируя Вас самого, "связи типа х и конкретной реализацией foo" ?
Если Вам не знаком термин "overloading" — на этот счет есть даже целая теория. В контексте HM(X)
Здравствуйте, awson, Вы писали:
A>Я же прямо написал: "Если Вы не используете overloading (ad hoc полиморфизм, см. ниже), Вам не нужно знать какого типа элементы в контейнере."
"overloading" это частный случай ad-hoc полиморфизма. т.е. "связь реализации foo c типом х" или, более общо — "разное действие функции на разный тип аргумента" может быть обечено многими споспобами, и то, что вы понимаете под "overoading" — только один из них. Это во-первых.
Во-вторых — я не вижу никакой связи между знанием типа элемента контейнера и использованием overloading-а.
A>*Зачем* Вам тип *iterator, если у Вас нет overloading? Т.е., если нет, цитируя Вас самого, "связи типа х и конкретной реализацией foo" ?
На редкость глупый вопрос. * мне нужна затем, чтобы получить по итератору элемент контейнера. Тип *iterator равен типу элемента контейнера, так что оператор * должен быть разным для разных инстансов контейнера с элементами разных типов. Отсюда следует, что vector<int>::iterator и vector<double>::iterator — разные типы. Причем тут overloading — мне не понятно. Вы вообще понимаете, о чем мы тут разговариваем с людьми? Или на слова знакомые реагируете, как поисковик "яндекс"?
A>Если Вам не знаком термин "overloading" — на этот счет есть даже целая теория. В контексте HM(X)
Причем здесь хиндли-милнер? Я не понинимаю ваши посты — они мне кажутся начисто лишенными смысла — потоком сознания каким-то.
machine3000 wrote:
> Специализация "В лорьке торгую" Специализация "Фигня фсякая", контекст > "деятельность, отличная от IT", степень соответствия ~90
"деятельность связанная с IT" — это в точности "Фигня всякая". А я вот в ларьке торгую
> Откуда У талкучки дом торцом, 4 этаж, дверь на право Откуда Бабруйск, > контекст "где-то не в Москве" степень соответствия ~65
Есть только 2 места на планете Земля — Москва и "где-то не в Москве"
> Первое сообщение 12.07.03 16:26 Первое сообщение 16.07.03 22:45, > контекст "число дней с 12.07.03" степень соответствия ~99.5
Ага, прикольно.
> Оценка коллег 577 (282) Оценка коллег 8079 (1722), контекст "разделение > спорных и рейтинговых высказываний" степень соответствия ~40
Офигеть, рейтинги совсем разные.
> + > Вход в дискуссию в середине ветви
Согласен, отвечать на сообщения глубже 3-4 уровней — только портить кровь.
> + > Ответ на сообщение, требующий изучения кода
А что его изучать? И так всё ясно.
> + > Совпадение точек зрения
Ну если для тебя есть две точки зрения "моя и неправильная", то все, кто не согласен с тобой, автоматически имеют одну
т.з.
Posted via RSDN NNTP Server 2.1 beta
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Gaperton, Вы писали:
G>На редкость глупый вопрос. * мне нужна затем, чтобы получить по итератору элемент контейнера. Тип *iterator равен типу элемента контейнера, так что оператор * должен быть разным для разных инстансов контейнера с элементами разных типов. Отсюда следует, что vector<int>::iterator и vector<double>::iterator — разные типы. Причем тут overloading — мне не понятно.
Это не вопрос глупый.
Так и быть, попробую объяснить совсем прямо на пальцах.
1. Когда Вам нужен элемент контейнера? Тогда, когда Вы хотите с ним что-нибудь сделать, т.е., написать функцию (метод — частный случай функции) которая на него подействует.
2. Когда Вам нужен *тип* этого элемента? Тогда, когда нужно "разное действие функции на разный тип аргумента" (это я опять Вас цитирую), потому что если бы интересующая Вас функция на аргументы разных типов действовала бы одинаково, Вам этот тип был бы *не нужен*.
3. По Вашему собственному определению, "разное действие функции на разный тип аргумента" называется overloading.
Что-то опять непонятно???
G>Вы вообще понимаете, о чем мы тут разговариваем с людьми? Или на слова знакомые реагируете, как поисковик "яндекс"?
Гм, это как раз про Вас. Если Вы что-то не понимаете, сначала думайте, если все же не понимаете, думайте еще. Потом *вежливо* просите разъяснить.
Здравствуйте, Gaperton, Вы писали:
A>>Если Вам не знаком термин "overloading" — на этот счет есть даже целая теория. В контексте HM(X)
G>Причем здесь хиндли-милнер? Я не понинимаю ваши посты — они мне кажутся начисто лишенными смысла — потоком сознания каким-то.
awson во много апеллирует в Haskell, я не спец, но немного на него посмотрел. Так вот простите за такое сравнение: реализация классов в Haskell в каком-то смысле схожа с шаблонами в С++
В Haskell (на сколько я помню) класс определяет функции, ктр должны быть реализованы для этого типа. Функция может принимать аргументы определенного класса (вне зависимости от реального типа) и работать с ним единообразно, ведь для все типов входящих в этот класс определены требуемые функции. Т.е. все прозрачно, всем рулит компилятор (тут и нужна система типов хиндли-милнера)
В С++ у нас будет шаблон, тип (параметр шаблона) — фактически аналог класса в Haskell, так как это тип должен реализовывать интерфейс который используется шаблоном (итераторы совместимые с STL должны поддерживать ++ и * по крайне мере). Только в случае С++, типа — параметры шаблонов видны в программе и фактически задаются ручками (ну кое-ггде их компилатор выводит)
Вот Gaperton и awson похоже спорят про одно и тоже, но Gapeton со стороны С++ смотрит, а awson со стороны Haskell
Здравствуйте, RailRoadMan, Вы писали:
RRM>awson во много апеллирует в Haskell
Haskell опыт дает очень ясную перспективу, потому что проясняет многие вещи.
Взять тот же overloading. Люди сплошь и рядом не отдают себе отчета в том, что даже в обычном С "=", "+", "-" и т.д. это overloaded операции. Я Gaperton'а читаю вскользь и сначала даже не обратил внимания на то, что он в одной фразе пишет одновременно и "оператор * должен быть разным для разных инстансов контейнера с элементами разных типов" и "причем тут overloading — мне не понятно"
Здравствуйте, awson, Вы писали:
A>Взять тот же overloading. Люди сплошь и рядом не отдают себе отчета в том, что даже в обычном С "=", "+", "-" и т.д. это overloaded операции. Я Gaperton'а читаю вскользь и сначала даже не обратил внимания на то, что он в одной фразе пишет одновременно и "оператор * должен быть разным для разных инстансов контейнера с элементами разных типов" и "причем тут overloading — мне не понятно"
"оператор * должен быть разным для разных инстансов контейнера с элементами разных типов" с этим я соглашусь, по крайне мере с той точки зрения, что это будет разный код (машинный)
"причем тут overloading — мне не понятно" и с этим одновременно соглашусь, просто в данном случае overloading с точки зрения С++, его нет. overloading в смысле ad-hoc полиморфизм — есть
Здравствуйте, RailRoadMan, Вы писали:
RRM>"оператор * должен быть разным для разных инстансов контейнера с элементами разных типов" с этим я соглашусь, по крайне мере с той точки зрения, что это будет разный код (машинный).
другой дело явно он будет присутствовать или компилатор его создаст, в С++ и Haskell степень автоматизации будетсущественно отличаться
Здравствуйте, RailRoadMan, Вы писали:
RRM>"причем тут overloading — мне не понятно" и с этим одновременно соглашусь, просто в данном случае overloading с точки зрения С++, его нет. overloading в смысле ad-hoc полиморфизм — есть
Вот это и называется разные перспективы. Я говорю о *принципиальных* вопросах, а не о том, что, типа, если ручками не написано, то "считается или нет?"
Здравствуйте, awson, Вы писали:
A>Здравствуйте, Gaperton, Вы писали:
G>>На редкость глупый вопрос. * мне нужна затем, чтобы получить по итератору элемент контейнера. Тип *iterator равен типу элемента контейнера, так что оператор * должен быть разным для разных инстансов контейнера с элементами разных типов. Отсюда следует, что vector<int>::iterator и vector<double>::iterator — разные типы. Причем тут overloading — мне не понятно.
A>Это не вопрос глупый.
Чтобы вопрос был не глупым — надо уметь формулировать мысль ясно и четко. Ты спрашиваешь
A>*Зачем* Вам тип *iterator, если у Вас нет overloading?
Этот вопрос глупый. Такой вопрос надо в конференцию "юмор" посылать. Зачем мне тип *iterator — глупый вопрос, добавка "если у меня нет overloading" — тоже глупая, так как я не понимаю, почему это вдруг "у меня нет overloading". Вместе — вопрос глупый в квадрате — я не понимаю, как связаны эти фразы.
A>Так и быть, попробую объяснить совсем прямо на пальцах.
Обойдись без "так и быть". Тебя об одолжениях тут вообще-то никто не просит. Это я тебе делаю одолжение, что на твой хреново сформулированый вопрос отвечаю. Хамство твое начинает доставать.
A>1. Когда Вам нужен элемент контейнера? Тогда, когда Вы хотите с ним что-нибудь сделать, т.е., написать функцию (метод — частный случай функции) которая на него подействует. A>2. Когда Вам нужен *тип* этого элемента? Тогда, когда нужно "разное действие функции на разный тип аргумента" (это я опять Вас цитирую), потому что если бы интересующая Вас функция на аргументы разных типов действовала бы одинаково, Вам этот тип был бы *не нужен*.
Мне *тип* этого элемента вообще не нужен. Он нужен компилятору, всегда, когда происходит обращение к элементу. В том числе и не в ad-hoc полиморфной, а в самой обычной функции.
A>3. По Вашему собственному определению, "разное действие функции на разный тип аргумента" называется overloading.
Повторяю. По определению, и не моему, а общеизвестному, это называется ad-hoc полиморфизнм. Overloading — частный его случай. Это ты думаешь, что это одно и тоже — не я. Но тебе объяснять что-либо просто бесполезно — только портить.
G>>Вы вообще понимаете, о чем мы тут разговариваем с людьми? Или на слова знакомые реагируете, как поисковик "яндекс"? A>Гм, это как раз про Вас. A>Если Вы что-то не понимаете, сначала думайте, если все же не понимаете, думайте еще. Потом *вежливо* просите разъяснить.
Странная претензия от хама. Я с тобой вообще разговаривать не хочу.
Здравствуйте, Gaperton, Вы писали:
G>Этот вопрос глупый. Такой вопрос надо в конференцию "юмор" посылать. Зачем мне тип *iterator — глупый вопрос, добавка "если у меня нет overloading" — тоже глупая, так как я не понимаю, почему это вдруг "у меня нет overloading". Вместе — вопрос глупый в квадрате — я не понимаю, как связаны эти фразы.
Это мое последнее общение с тобой на эту тему, поэтому я в 3-й раз напомню контекст
: Если Вы не используете overloading (ad hoc полиморфизм, см. ниже), Вам не нужно знать какого типа элементы в контейнере.
И еще раз повторю — если ты чего-то не понимаешь, сначала подумай, а потом попроси объяснить.
G>Мне *тип* этого элемента вообще не нужен. Он нужен компилятору, всегда, когда происходит обращение к элементу. В том числе и не в ad-hoc полиморфной, а в самой обычной функции.
Он будет нужен компилятору если ты напишешь такую функцию через жопу. Потому что, если "самая обычная" функция не зависит от типа параметра, ее всегда можно написать так, чтобы этот тип компилятору не понадобился. Я догадываюсь, что с пониманием этого простого факта у тебя также возникнут проблемы, поэтому можешь заглянуть сюда
.
G>Повторяю. По определению, и не моему, а общеизвестному, это называется ad-hoc полиморфизнм. Overloading — частный его случай. Это ты думаешь, что это одно и тоже — не я. Но тебе объяснять что-либо просто бесполезно — только портить.
Булшит. Сплошь и рядом у серьезных людей (а не писателей пособий для ПТУ) это — синонимы.
L>>Согласная я!!! Даёшь меанизм замыканий в С++!!!
VD>Ага, еще добавить: VD>1. Автоматическое управление память. VD>2. Убрать UB. VD>3. Ввести режим полной типобезпасности. VD>...
Да не, зачем мне ещё один C#/Java? Их и так уже юзают вместо С++ везде где это можно, и думаю что это хорошо. Но вот можно это далеко не везде Всё что мне нужно — это C++ с современным синтаксическим сахаром.
Ну, хотя насчёт UB конечно согласен — детских граблей в высокой траве С++ могло бы лежать и поменьше
Здравствуйте, Left2, Вы писали:
L>Да не, зачем мне ещё один C#/Java?
Как минимум шаблонов в них нет.
L> Их и так уже юзают вместо С++ везде где это можно, и думаю что это хорошо. Но вот можно это далеко не везде Всё что мне нужно — это C++ с современным синтаксическим сахаром.
Как минимум без п. 1. это невозможно.
Ну, а мне убожество вроде С++ вообще не нужно. Мне скорее хотелось бы некоторые качества С++ которые сейчас присутсвуют в его реализациях видить в более современных языках.
L>Ну, хотя насчёт UB конечно согласен — детских граблей в высокой траве С++ могло бы лежать и поменьше
Не понял подмигивания.
... << RSDN@Home 1.2.0 alpha rev. 637>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>И что из этого? Объекты перестают быть объектами? o_O
В общем-то да. Теоретически, никто не запрещает этому "объекту" быть просто парой функций current и next.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, deniok, Вы писали:
D>Это не "чистые" функции. Они апеллируют к некоторому состоянию, являясь интерфейсом его итерирования. Вот это и задаст объект (не итератор, а собственно контейнер). STL — не чистое ФП, потому что контейнеры по дизайну представляют собой объекты с состоянием. В чистом ФП список или дерево — просто набор вызовов разных конструкторов (для списка, скажем, Nil, Cons что-то, Cons что-то, ...), а итерирование идёт через паттерн матчинг по видам конструкторов и рекурсию. При таком итерировании происходит обратный разбор и возможна дефорестация при компиляции: то есть список, как объект в памяти, может вообще не создаваться.
Cтрого говоря, в примере с deque и vector никакой функции "current" у меня нет и print_container никаким "состоянием" контейнера не пользуется ну и, соответственно, его не меняет. Я назвал параметр именем state, чтобы продемонстрировать именно эксплицитную передачу "состояния", а не его мутацию. Я, конечно, не стал возиться с конструкторами и темной историей с "end", но, думаю, идею передал верно.
Здравствуйте, deniok, Вы писали:
D>STL — не чистое ФП, потому что контейнеры по дизайну представляют собой объекты с состоянием. В чистом ФП список или дерево — просто набор вызовов разных конструкторов (для списка, скажем, Nil, Cons что-то, Cons что-то, ...)
От того что состояние хранится в стеке оно состоянием быть не перестает.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, deniok, Вы писали:
D>>STL — не чистое ФП, потому что контейнеры по дизайну представляют собой объекты с состоянием. В чистом ФП список или дерево — просто набор вызовов разных конструкторов (для списка, скажем, Nil, Cons что-то, Cons что-то, ...)
AVK>От того что состояние хранится в стеке оно состоянием быть не перестает.
Вся фишка в элиминировании избыточного состояния. В STL наивный программист может считать данные из одного файла в один контейнер, из другого в другой, выполнить какой-нибудь transform этих двух в третий, отфильтровать этот третий и запустить по нему некоторое агрегатное вычисление. Изощрённый программист увидит, что можно повесить итераторы ввода на оба файла и создать функтор, который генерирует тот же результат, не создавая ни одного контейнера.
Современные компиляторы чистых функциональных языков (GHC для Хаскелла) сами занимаются такой оптимизацией, называемой дефорестацией. Мы пишем код эквивалентный коду наивного программиста, используя столько списков сколько влезет. Но в реальности во время исполнения промежуточные списки не создаются — map'ы и fold'ы над ними эффективно дефорестируются.
L>>Да не, зачем мне ещё один C#/Java? VD>Как минимум шаблонов в них нет.
Ну вон C++/CLI есть — в и шаблоны и женерики и к тому же друг с другом скрещиваются. Но только заставить заработать этот C++/CLI на какой-нить железяке с 64к памяти ой как проблематично. Да даже не с 64к а 4м — маловато ему... А рынок встраиваемых железяк растёт ой как шустро, и софта под них надо будет ой как много...
L>> Их и так уже юзают вместо С++ везде где это можно, и думаю что это хорошо. Но вот можно это далеко не везде Всё что мне нужно — это C++ с современным синтаксическим сахаром. VD>Как минимум без п. 1. это невозможно.
Это невозможно сделать безопасно. Но меня вполне устроит и небезопасный вариант — вон, контейнеры STL небезопасны из-за того что итераторы становятся невалидными — то же поведение (не уследил за временем жизни переменной -> сам дурак -> получи креш в run-time) вполне устроит меня и для замыканий.
VD>Ну, а мне убожество вроде С++ вообще не нужно. Мне скорее хотелось бы некоторые качества С++ которые сейчас присутсвуют в его реализациях видить в более современных языках.
Ну раз не нужно — ну и не пользуйся Зачем кидаться-то на С++ как бык на красную тряпку?
L>>Ну, хотя насчёт UB конечно согласен — детских граблей в высокой траве С++ могло бы лежать и поменьше VD>Не понял подмигивания.
Никакой конспиралогии. Прошу не воспринимать на свой счёт. Иногда люди просто улыбаются
G>STL хорош не потому, что это сочетание ФП и ООП. STL хорош потому, что прост, удобен, красив, и понятен. В STL нет ничего лишнего — ни добавить, ни прибавить. Вот когда мы попытаемся разобраться, как STL устроен, на каких принципах, и на что он похож — то станет видно, что все в сущности проще, настолько просто, что не надо никаких "новых парадигм" выдумывать, вроде generic programming. Станет понятно, например, что в таком стиле легко писать на JavaScript — легче, чем на С++, и безо всяких темплейтов.
Про JavaScript — абсолютно согласен То-то я, старый дурак, всю жизнь писавший на плюсах влюбился в JS без памяти Причём поначалу пытался писать на JS в OO-стиле — создавал обьекты которые наследовались друг от друга и т.п. Но чуть погодя понял что лезу со своим уставом в чужой монастырь, что в JS всё делается куда проще и красивее — что куда проще оперировать создаваемыми на лету функциями чем наворачивать базовые классы и перекрывать поведение у наследников
Здравствуйте, Left2, Вы писали:
L>>>Да не, зачем мне ещё один C#/Java? VD>>Как минимум шаблонов в них нет. L>Ну вон C++/CLI есть — в и шаблоны и женерики и к тому же друг с другом скрещиваются. Но только заставить заработать этот C++/CLI на какой-нить железяке с 64к памяти ой как проблематично. Да даже не с 64к а 4м — маловато ему... А рынок встраиваемых железяк растёт ой как шустро, и софта под них надо будет ой как много...
L>>>>Да не, зачем мне ещё один C#/Java? VD>>>Как минимум шаблонов в них нет. L>>Ну вон C++/CLI есть — в и шаблоны и женерики и к тому же друг с другом скрещиваются. Но только заставить заработать этот C++/CLI на какой-нить железяке с 64к памяти ой как проблематично. Да даже не с 64к а 4м — маловато ему... А рынок встраиваемых железяк растёт ой как шустро, и софта под них надо будет ой как много... FR>D не смотрел?
Здравствуйте, awson, Вы писали:
A>Например (самый тривиальный), Вам не нужно знать, какого типа элементы в контейнере, чтобы посчитать их количество.
А как это сделать? В STL используются 2 варианта: хранить количество добавляемых объектов или вызвать специализированныый для конкретного типа std::distance.
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird (c) D.Knuth
