Именно с него всё это и пишу, "Язык программирования C++ 3-е издание", у меня бумажная версия с 1999 года, и пожалуй эту книгу я уважаю больше всех по тематике C++. То что пока тут написал относится к главам с 10 по 15 - механизмы абстракции.


Первое не читал, второе читал. Сразу стоит отметить, что у Александреску другой подход, не такой как у Страуструпа, а я больше склоняюсь к идеям последнего. К тому же я не заставляю людей пользоваться тем, что описал. Это не более чем мысли вслух, большая часть которых остаётся невысказанной. В рассуждениях уже докатился до универсальной абстракции с которой можно построить абстракцию для построения программ на реальных объектно-ориентированных системах программирования, в основе которые даже не важно какой язык, C++, Java, C# или что-то другое.

Первая книга в деталях объясняет шаблоны. Вторая показывает как можно их использовать. Без понимания первой, понять вторую достаточно проблематично, хотя, конечно, возможно, но поверхностно. Приниматься за проектирование на любом языке стоит только после изучения его возможностей. Шаблоны не следует упускать из виду...

По поводу книжки Страуструпа - шаблоны и их возможности, затронуты недостаточно глубоко. Я думаю, ему просто не хватило места. Объём книги мог увеличится как минимум в полтора раза. А Мейерса всё же стоит почитать. Тем более, читатется лекго и непринуждённо, после Страуструпа. 

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

Это сообщение отредактировал(а) Леопольд - 18.6.2009, 07:43

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


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


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

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

Здесь так же стоит отметить, что STL и Boost это стиль Александреску, то есть там нет чёткого разделения указанного выше. Мне это больше напоминает модульное программирование, когда есть классы заключающие в себе наборы функций вне зависимости от принадлежности, или вообще находящиеся в глобальном пространстве имён.

это как? давай на конкретных примерах, а то у меня нет времени все это читать

Ну давай. Обычно когда люди берут STL, они сбрасывают пространство имён std до глобального. Проблема в том, что каких-либо ещё уровней вложения особо и не предусмотрено. Даже если каждый раз писать std:: с точки зрения проектирования это ничем не отличается от глобального пространства, максимум может дать защиту от пересечений с собственной библиотекой программиста.

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

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

Это проблема людей, а не библиотеки

Это тоже библиотеку никоем образом не касается


А какую защиту Вы еще хотите ?


Да это не ООП, это следующий уровень абстракции. 


Нет, то что Стл такая,  это влияние Степанова 




Это сообщение отредактировал(а) mes - 18.6.2009, 15:08

Объясни мне, как ты собираешься реализовать в ООП стиле алгоритм sort, или for_each?
Если следовать твоей логике, то нужно каждому контейнеру добавить метод sort, да?
Вот теперь смотри, тебе понадобится по одному методу sort без параметров а так-же по методу sort(iterator iterator)(так-как мне может понадобиться отсортировать только часть данных), для каждого типа контейнера. Дальше, это все будет работать для контейнеров, но не будет работать для обычных указателей. Потом, разработчики, реализующие свои контейнеры, должны будут реализовать эти методы для своих контейнеров, если они хотят, что-бы они были stl совместимы. А еще у нас не один алгоритм sort, у нас много разных алгоритмов. Если ты знаком с комбинаторикой, то ты сможешь представить сколько кода придется написать только для stl, а сколько кода придется писать другим разработчикам - вряд-ли сможешь  .
Это плохой дизайн.
В то-же время в STL все это сделано очень просто. У каждого контейнера есть методы возвращающие пару итераторов: begin и end, эти итераторы могут быть разных категорий - ForwardIterator, ReverseIterator, RandomAccessIterator. На этапе компиляции можно выяснить, к какой категории принадлежит этот итератор с помощью класса std::iterator_traits, а так-же с его помощью можно получить тип значения или ссылки. Это так-же работает для обычных указателей. Алгоритмы принимают итераторы(которые могут быть чем угодно) и получают все нужные им типы данных с помощью iterator_traits, они могут быть реализованы по разному для разных типов итераторов.
В итоге мы имеем следующее: не ООП алгоритмы работают с чем угодно; они могут быть специализированы для разных частных случаев; они могут работать с классами о которых разработчики стандартной библиотеки не имели представления; разработчикам достаточно написать класс - итератор для своих классов коллекций и все алгоритмы будут работать для их классов; можно писать STL совместимые алгоритмы, которые будут работать так-же как и стандартные, к примеру можно реализовать radix_sort, который будет работать с std::vector<..>, в случае, если алгоритмы будут методами - это будет невозможно. Одним словм, это правильный дизайн.  


во первых то, что есть в std зависит от того, какие заголовочные файлы подключены, во вторых, пространство имен std можно расширять, к примеру новыми алгоритмами, или можно специализировать iterator_traits для своего итератора и так далее  

Это сообщение отредактировал(а) Lazin - 18.6.2009, 15:50

  
кстати - std::string прекрасный пример того, чтобы произошло если

а если быть точнее - логике unicuum.
Саттера в своей книге more exceptional C++ упоминает об этом. Сколько там функций было? 44 кажется, не помню точно. Так вот, очень многие из этих функций можно было бы вынести за рамки класса, и это было бы правильнее. Например функция empty(). Она написана в каждом контейнере отдельно, хотя могла бы быть одна на всех.

там много чего написано, не хочу сейчас все цитировать. Но СТЛ даже более обьектен чем следовало бы.

Не нужно комбинировать больше семи членов, сначало делают, потом удивляются что ООП уродское, а это не ООП на самом деле.


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

Не нужно забывать, что методы классов можно сделать статическими, не обязательно использовать их через объект. Здесь дело в логической связи между тем, что лежит в одном классе, именно тот самый шаблон функционального дизайна описанный выше - класс должен отвечать за минимальную область деятельности. Чтобы скомбинировать методы в одном классе, они должны быть по настоящему связаны. Если таких классов наберётся много за связь должны отвечать пространства имён, но не нужно пытаться выполнить их роль, за счёт засовывания методов в один класс.

откройте для себя АОП : http://ru.wikipedia.org/wiki/%D0%90%D1%81%...%BD%D0%B8%D0%B5 
может тогда получится понять, что ООП это не панацея.


P.S. Вы зачастую приводите чужую одностороннюю  точку зрения, забывая что каждый кулик свое болото хвалит.



Это сообщение отредактировал(а) mes - 18.6.2009, 17:50

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

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

Добавлено @ 18:20

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

Это сообщение отредактировал(а) mes - 18.6.2009, 18:20

тебе не кажется

что ты сам себе противоречишь?

на самом деле мой пост не о шаблонах, там фигурируют паттерны проектирования iterator и inversion of control (разрыв мозгазависимости)  
и где интересно я выступаю против ООП?  

а почему именно 7, а не 8? 
а если мне нужно перегрузить метод для множества разных аргументов, это по уродски или нет?  

о боже мой, а мы и не знали!!  
статическим, метод может быть тогда, когда он не использует данные экземпляра объекта, а если использует, то ты только усложнишь себе жизнь...


пространства имен это фикция, в ООП нет такого понятия, это синтаксический сахар  
ты не видишь разницу между реальноми возможностями языка программирования и синтаксическим сахором, который призван улучшить читаемость кода  


вообще, обсуждение ушло куда-то не туда, лично я готов обсуждать что-либо имеющее отношение к практике, к примеру какой-либо случай применения определенного паттерна, а пустая болтовня только зря отнимает время  

"Совершенный код" Макконнелл (стр.140)
6.3. Вопросы проектирования и реализации
подпункт Включение (отношение "содержит")

***
unicuum и atomicxp очень любят число СЕМЬ!   
привожу их цитаты:








***
интересно проследить, как рекомендация стала правилом:
Макконнелл:

atomicxp | unicuum



Это сообщение отредактировал(а) zim22 - 18.6.2009, 19:59

Ну, это я один на самом деле, хотя не важно.