Re[4]: Кстати об ООП дизайне
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 06.01.04 07:41
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>C++ дает возможность реализовать любую стратегию выделения и освобождения памяти, в том числе и сборку мусора like Java.

Ну, если быть совсем честным, то именно "как Java" не выйдет. Java (как и .NET) использует метаданные для анализа графа достижимости. В плюсах придется предоставлять эти метаданные вручную (например, регистрировать указатели).
Д>Другой вопрос уже — какими трудозатратами это обернется. Есть и еще более оптимальные варианты Например — выделять часть своих объектов в специальном пуле, а когда они стали не нужны — просто убить этот пул вместе со всеми объектами.
Согласен. На плюсах можно реализовать очень неплохbt сценарии управления памятью. Но основная проблема в том, что все они требуют использования вспомогательных классов вместо С-style указателей и функций. При этом запретить использование такого legacy-подхода нельзя. А это означает, что нерадивый программист где-то вызовет malloc — и упс...
Д>Ну и прямые руки опять же очень нужны... а за прямые руки нужно хорошо платить — проще нанять пару-тройку недоученных студентов и посадить за яву.
Именно. Хороший код малыми силами — вот наш девиз.
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[5]: Кстати об ООП дизайне
От: Дарней Россия  
Дата: 06.01.04 13:19
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Дарней, Вы писали:


S>Ну, если быть совсем честным, то именно "как Java" не выйдет. Java (как и .NET) использует метаданные для анализа графа достижимости. В плюсах придется предоставлять эти метаданные вручную (например, регистрировать указатели).


угу. smart-pointer'ы или макросы (тьфу-тьфу-тьфу) наверняка спасут отца русской демократии. Хотя если быть совсем уж честным, реализации метаданных для С++ тоже есть — Qt, например. Если нет желания завязываться на библиотеку — можно использовать аналогичный подход и сделать своими силами хотя бы простенький генератор метаданных (не так это и страшно, как звучит)

S>Согласен. На плюсах можно реализовать очень неплохbt сценарии управления памятью. Но основная проблема в том, что все они требуют использования вспомогательных классов вместо С-style указателей и функций. При этом запретить использование такого legacy-подхода нельзя. А это означает, что нерадивый программист где-то вызовет malloc — и упс...


безусловно — помешать кому-то накосячить в С++ никак не получится. А использовать вспомогательные классы — это совсем не проблема, на то и есть шаблоны.

S>Именно. Хороший код малыми силами — вот наш девиз.


Так что преимущества Явы по скорости — это спекуляция...
При желании и наличии ресурсов (sic!) код на С++ можно оптимизировать так, что любой managed-код будет плестись далеко в хвосте. При сравнениях Java vs C++ vs .NET про возможности оптимизации обычно забывают.
Хотя возможно, что введение генериков в .NET разрыв подсократит — посмотрим, что у них получится
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Кстати об ООП дизайне
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 06.01.04 14:13
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>Так что преимущества Явы по скорости — это спекуляция...

Д>При желании и наличии ресурсов (sic!) код на С++ можно оптимизировать так, что любой managed-код будет плестись далеко в хвосте. При сравнениях Java vs C++ vs .NET про возможности оптимизации обычно забывают.
Такой подход нас заведет очень далеко. Потому, что в managed коде тебе никто не запрещает выделить один раз пару сотен метров под байтовый массив и реализовать свой deterministic finalization поверх него. Корявенько конечно будет, но "далеко в хвосте" превратится в лучшем случае в "плотно в затылок". Подобный подход на самом деле используется народом, который клепает performance-critical сервисы на жабе. И он действительно сильно помогает.
В общем, предлагаю этот подход замять и подумать над тем, какие возможности по оптимизации общих алгоритмов предоставляют наши подходы. Плюсы несомненно быстрее С, как я уже упоминал, по простой причине — они позволяют написать алгоритмы более общего вида, преобразующиеся в тот же самый asm, что и частные алгоритмы на С. С быстрее ассемблера потому, что на нем можно написать алгоритмы более общего вида. Когда выходит новый процессор, нам уже не надо скрупулезно менять местами опкоды, учитывая его особенности — достаточно просто перекомпилять новым компилятором.
Теперь поглядим на managed среды. В пассиве у них GC. А что в активе?
— JIT теоретически может генерить более оптимальный код, благодаря тому, что он компиляет не под x86 Blend, а под конкретный Model, Stepping, и Extension Set.
— Хотспоттинг теоретически позволяет делать глобальные оптимизации, недоступные С++ по определению (если только не весь код лежит в одном main.cpp )
Д>Хотя возможно, что введение генериков в .NET разрыв подсократит — посмотрим, что у них получится
Верно. Посмотрим, что они сделают к версии 1.5 Пока что у .NET по поводу производительности есть теоретические преимущества и практические недостатки . Хотя это, конечно же, не умалает его практических преимуществ по скорости разработки (а мы действительно живем в таком мире, где для подавляющего большинства софта Time To Market играет значительно более важную роль, чем performance. Возможность выпустить продукт на полгода раньше конкурентов вполне может привести к захвату рынка, несмотря на 50% недостаток в производительности. Увы.)
... << RSDN@Home 1.1.2 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[7]: Кстати об ООП дизайне
От: Дарней Россия  
Дата: 08.01.04 11:54
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Дарней, Вы писали:


S>Такой подход нас заведет очень далеко. Потому, что в managed коде тебе никто не запрещает выделить один раз пару сотен метров под байтовый массив и реализовать свой deterministic finalization поверх него. Корявенько конечно будет, но "далеко в хвосте" превратится в лучшем случае в "плотно в затылок". Подобный подход на самом деле используется народом, который клепает performance-critical сервисы на жабе. И он действительно сильно помогает.


таки да. С другой стороны — и все преимущества GC такой подход сведет на нет, и даст разработчикам широкое поле для совершения косяков

S>В общем, предлагаю этот подход замять и подумать над тем, какие возможности по оптимизации общих алгоритмов предоставляют наши подходы. Плюсы несомненно быстрее С, как я уже упоминал, по простой причине — они позволяют написать алгоритмы более общего вида, преобразующиеся в тот же самый asm, что и частные алгоритмы на С. С быстрее ассемблера потому, что на нем можно написать алгоритмы более общего вида. Когда выходит новый процессор, нам уже не надо скрупулезно менять местами опкоды, учитывая его особенности — достаточно просто перекомпилять новым компилятором.


с этим еще можно поспорить. Без агрессивной оптимизации кода (которая зачастую приводит к вырождению проги из С++ в "плоский" С) прога на С++ будет все-таки медленнее, чем сишная прога. За всё нужно расплачиваться, за удобство программирования — в том числе.
Положение выравнивается только благодаря шаблонам (пример с сортировкой массива через std::sort и сишный sort — это уже просто классика). Только много ли програмеров толково их используют?

S>Теперь поглядим на managed среды. В пассиве у них GC. А что в активе?


я бы назвал еще возможность динамической генерации кода — в потенциале тоже очень могучий механизм оптимизации

S>Верно. Посмотрим, что они сделают к версии 1.5 Пока что у .NET по поводу производительности есть теоретические преимущества и практические недостатки .


это был бы просто праздник Ну а пока у них получается на удивление достойный продукт (за вычетом некоторых странностей)... который наверняка займет определенную нишу
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re: Кстати об ООП дизайне
От: Slick Украина  
Дата: 09.01.04 13:42
Оценка:
Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Вот отрывок из книши одного очень хорошего писателя:

H_D>
H_D>      - Долгая история. Все дело в том, что местные программисты пошли
H_D>по неверному пути. Этот путь называется объектно ориентированный подход
H_D>в программировании. На самом деле это мина с часовым механизмом в
H_D>красивой упаковке. В очень красивой упаковке. Как с этим бороться, я
H_D>не знаю. Упустил момент.
H_D>      - Мастер, ближе к делу.
H_D>      - Знаешь анекдот, как программист кипятит чайник. Дано: пустой
H_D>чайник, кран, спички, газовая плита. Программа действий: наполнить
H_D>чайник водой из-под крана, поставить на плиту, зажечь газ. Ждать, пока
H_D>закипит чайник. Эта программа оформляется как объект. Второй случай.
H_D>Все то же самое, но чайник с водой уже стоит на плите. Действия
H_D>программиста: вылить воду из чайника и выполнить предыдущий объект.
H_D>      - Грустно. А нырнуть внутрь объекта нельзя? Туда, где надо газ
H_D>зажечь?
H_D>      - Нельзя. Можно добавить новое свойство или действие. В нашем случае
H_D>- воду вылить. Будет новый объект. Но внутрь влезть нельзя. Объект дается
H_D>как единое целое. Никто не знает, что там внутри. Все давно забыли, откуда
H_D>ноги растут. В результате получается колоссальное дублирование кода и данных
H_D>и огромная потеря производительности компьютера. С каждым годом компьютеры
H_D>требуют все больше памяти, а работают все медленнее.
H_D>

H_D>Которая лишь подтверждает мысль, что ООП везде — это вред и блед, хотя и не отрицает что в бизнес приложениях ООП — это просто круто


Да ну, бред какой. Да, есть такой прием в риторике — сделать заведомо ложное утверждение, а на его основе построить цепочку логичных следствий. Поскольку следствия действительно объективны, то оппнент теряет из виду тот факт, что сделаны то они на основе ложного утверждения.

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


Это при том, что одно из основных назначений ООП — повторное использование, т.е. борьба с дублированием.
Что касается конкретного примера — там надо унаследоваться от этого объекта перекрыть метод "зачечь газ", добавив туда проверку на наличие воды.
И вообще, там допущена грубая ошибка проектирования: действия по своей природе не являющиеся атомарными, объединены в одну транзакцию.

Так что проблема не в ООП, а в неверном понимании ООП.
Re[3]: Кстати об ООП дизайне
От: Poudy Россия  
Дата: 13.01.04 07:22
Оценка:
Здравствуйте, Hacker_Delphi, Вы писали:

H_D>Нет нельзя.. представь, что вместо чайника — объект ядра ОС... (там-то про то, что ОСы ОО стали).

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

Т.е. недовольство вызвано тем, что в ОО ОСях нельзя менять ядро? Странно это ))))))))))))

P.S. принимайте все за шутку, как и дурь про чайник.
Re[8]: Кстати об ООП дизайне
От: Poudy Россия  
Дата: 13.01.04 07:40
Оценка:
Здравствуйте, Дарней, Вы писали:

Д>таки да. С другой стороны — и все преимущества GC такой подход сведет на нет, и даст разработчикам широкое поле для совершения косяков


Короче говоря, все это очень старые и очень распространенные заблуджения. И что языки высокого уровня медленнее, и что сборка мусора снижает производительность, и что XML ПО СУТИ страшно тормозно. Спорить можно, но бесполезно. Я так думаю, что эти заблуждения сродни еще одному — "про мышку и клавиатуру", связано непонятно с чем и неисправимо.
Re[9]: Кстати об ООП дизайне
От: Дарней Россия  
Дата: 13.01.04 09:38
Оценка:
Здравствуйте, Poudy, Вы писали:

P>Короче говоря, все это очень старые и очень распространенные заблуджения. И что языки высокого уровня медленнее, и что сборка мусора снижает производительность, и что XML ПО СУТИ страшно тормозно. Спорить можно, но бесполезно. Я так думаю, что эти заблуждения сродни еще одному — "про мышку и клавиатуру", связано непонятно с чем и неисправимо.


и практика эти "заблуждения" прекрасно подтверждает, как ни странно. Обидно, да?
Всех излечит, исцелит
добрый Ctrl+Alt+Delete
Re[6]: Люблю когда ставят минусы без аргументов.
От: Larm Украина  
Дата: 16.02.04 15:20
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

Ну, любезный, у меня Office XP работал на P166MMX, 48 MB RAM. И при этом бытсрее, чем 97. А до этого стоял Office 2000. Он тоже быстрее 97, хотя и медленнее XP. Так что не надо — сначала проверяйте, а потом слова собеседника сомнению подвергайте!
The God who walks is among us...
Re: Кстати об ООП дизайне
От: Larm Украина  
Дата: 16.02.04 15:40
Оценка: :)
Вы, люди, как обычн опоняли все буквально... Жаль вас, недалеко ушли
Имеется в виду (по сюжету он это рассказывает через N лет после запуска всех этих классов в работу), что когда библиотека классов разрастается (не как STL , а тысячи раз больше), то ты или вообще не имеешь доступа к исходному коду тех первоначальных объектов, либо разбирательство с ними займет ОЧЕНЬ много времени. Там шлось про какие-то очень адвансовые пакеты управления киберами или что-то в таком духе. Это тебе не строчки копировать Писалось все это не одним поколением программеров, так что переделать это — без шансов — там диаграмма иерархии на 900 гиг будет, а исполняются эти проги на сотнях параллельных процессоров (это у самы хпримитивных экземляров) . А вот брать и юзать готовые объекты и, если надо, добавлять в них новую функциональность,- это пожалуйста. Ну не знаешь ты, что этот объект отнаследован в 965 колене от другого, у которого можно немного изменить нужный метод. Пост был о том, что когда библиотека большая и тебе дейтсвительно надо ее расширить (не потратив полжизни на изучение ее структуры ), то возникает проблема того, что ты не знаешь, как оно работает. Вот это автор и хотел показать. В этом и есть проблема ООП, а не в том, что это медленнее функционального программирования на С
The God who walks is among us...
Re: Кстати об ООП дизайне
От: mister-AK Россия  
Дата: 16.02.04 17:01
Оценка:
Здравствуйте, Hacker_Delphi,


ну вобщем то наследование — это всего лишь иерархии... деревья... , а нам требуются ещё какие-нить иные отношения (не совсем реляционные)

например — слияние (абсорбирование, доминирование )

это даже наверное и верно... мина с часовым механизмом
а когда рванёт?
Re[4]: Кстати об ООП дизайне
От: mister-AK Россия  
Дата: 16.02.04 17:29
Оценка:
Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, dad, Вы писали:


К>>>Но инкапсуляция не есть фича ООП!!! Она также присуща и процедурному программированию.

К>>>В данном случае — имеем криво спроектированный процедурный API.

dad>>Как же инкапсуляция не фича ООП?

dad>>три фичи (кита) ООП — инкапсуляция полиморфизм и наследование. гыгы

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



мда.. значит кроме как наследование... у ООП нет явных приемуществ?! гы2
а экспонирование типов-интерфейсов?
Re[5]: Кстати об ООП дизайне
От: dad  
Дата: 16.02.04 17:36
Оценка:
К>>Полиморфизм и инкапсуляция также (в ограниченной степени) присущи процедурному программированию. С наследованием действительно обломс.


MA>мда.. значит кроме как наследование... у ООП нет явных приемуществ?! гы2

MA>а экспонирование типов-интерфейсов?

полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки
с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
и еще кое что. таковым является, например, ява.
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Re[6]: Кстати об ООП дизайне
От: mister-AK Россия  
Дата: 16.02.04 17:50
Оценка:
Здравствуйте, dad, Вы писали:


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



MA>>мда.. значит кроме как наследование... у ООП нет явных приемуществ?! гы2

MA>>а экспонирование типов-интерфейсов?

dad>полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки

dad>с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
dad>и еще кое что. таковым является, например, ява.

всё очень размыто...

многопоточность — это всего лишь один из классов при чем тут ОО...

а ...создания классов... я бы сказал... конструкторы экземпляров классов
Re[7]: Кстати об ООП дизайне
От: dad  
Дата: 18.02.04 05:01
Оценка:
MA>>>мда.. значит кроме как наследование... у ООП нет явных приемуществ?! гы2
MA>>>а экспонирование типов-интерфейсов?

dad>>полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки

dad>>с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
dad>>и еще кое что. таковым является, например, ява.

MA>всё очень размыто...


это у тебя размыто.

MA>а ...создания классов... я бы сказал... конструкторы экземпляров классов

нет именно определения классов, поскольку создавать объекты класса ты можешь и в явескрипт
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Re[8]: Кстати об ООП дизайне
От: Sinclair Россия http://corp.ingrammicro.com/Solutions/Cloud.aspx
Дата: 18.02.04 05:17
Оценка: +1
Здравствуйте, dad, Вы писали:
dad>нет именно определения классов, поскольку создавать объекты класса ты можешь и в явескрипт
в javascript классов нет. Там только объекты.
... << RSDN@Home 1.1.3 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
http://rsdn.org/File/5743/rsdnaddict.GIF
Re[3]: Кстати об ООП дизайне
От: Plutonia Experiment Беларусь http://blogs.rsdn.org/ikemefula
Дата: 18.02.04 09:40
Оценка:
Здравствуйте, Ведмедь, Вы писали:

В>Ну почему надо цепляться за конкретный пример и говорить, что пример неправильный, поэтому автор не прав?


Исходная посылка неверна, следовательно статья смысла не имеет.

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


Это пальцем в небо. Еси процедура написана, то нихрена ты с ней не сделаешь. Если программа написана, тож самое. Куда ни ткни, то все парадигмы отстойные. Пишется всягда то, что надо в лижайшем и немного отдаленном удущем. Как написать нечто на все случаи жизни знает только великий Джа. Я так не умею.
Re[8]: Кстати об ООП дизайне
От: mister-AK Россия  
Дата: 18.02.04 10:33
Оценка:
Здравствуйте, dad, Вы писали:

dad>>>полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки

dad>>>с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
dad>>>и еще кое что. таковым является, например, ява.

MA>>а ...создания классов... я бы сказал... конструкторы экземпляров классов


dad>нет именно определения классов, поскольку создавать объекты класса ты можешь и в явескрипт


разработка с использованием наследования = создание (написание ) классов
наверно руками или с помощью RAD?
Re[2]: Кстати об ООП дизайне
От: maikLa Россия  
Дата: 18.02.04 10:47
Оценка:
Здравствуйте, Larm, Вы писали:

L> Там шлось про какие-то очень адвансовые пакеты управления киберами или что-то в таком духе. Это тебе не строчки копировать Писалось все это не одним поколением программеров, так что переделать это — без шансов — там диаграмма иерархии на 900 гиг будет, а исполняются эти проги на сотнях параллельных процессоров (это у самы хпримитивных экземляров) .


Да-а... Зачем только с ООП связались, глупые... Не связывались бы => не написали бы столько... (вообще бы не написали почти ничего) => и проблем не было бы... и киберов этих... кому они только нужны?

L> А вот брать и юзать готовые объекты и, если надо, добавлять в них новую функциональность,- это пожалуйста. Ну не знаешь ты, что этот объект отнаследован в 965 колене от другого, у которого можно немного изменить нужный метод. Пост был о том, что когда библиотека большая и тебе дейтсвительно надо ее расширить (не потратив полжизни на изучение ее структуры ), то возникает проблема того, что ты не знаешь, как оно работает. Вот это автор и хотел показать. В этом и есть проблема ООП, а не в том, что это медленнее функционального программирования на С


В этом и есть проблемма больших библиотек.
Re[9]: Кстати об ООП дизайне
От: dad  
Дата: 18.02.04 10:52
Оценка:
dad>>>>полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки
dad>>>>с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
dad>>>>и еще кое что. таковым является, например, ява.

MA>>>а ...создания классов... я бы сказал... конструкторы экземпляров классов


dad>>нет именно определения классов, поскольку создавать объекты класса ты можешь и в явескрипт


MA>разработка с использованием наследования = создание (написание ) классов

MA>наверно руками или с помощью RAD?

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