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

Д>C++ дает возможность реализовать любую стратегию выделения и освобождения памяти, в том числе и сборку мусора like Java.
Ну, если быть совсем честным, то именно "как Java" не выйдет. Java (как и .NET) использует метаданные для анализа графа достижимости. В плюсах придется предоставлять эти метаданные вручную (например, регистрировать указатели).
Д>Другой вопрос уже — какими трудозатратами это обернется. Есть и еще более оптимальные варианты Например — выделять часть своих объектов в специальном пуле, а когда они стали не нужны — просто убить этот пул вместе со всеми объектами.
Согласен. На плюсах можно реализовать очень неплохbt сценарии управления памятью. Но основная проблема в том, что все они требуют использования вспомогательных классов вместо С-style указателей и функций. При этом запретить использование такого legacy-подхода нельзя. А это означает, что нерадивый программист где-то вызовет malloc — и упс...
Д>Ну и прямые руки опять же очень нужны... а за прямые руки нужно хорошо платить — проще нанять пару-тройку недоученных студентов и посадить за яву.
Именно. Хороший код малыми силами — вот наш девиз.

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

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

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

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

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

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

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

Так что преимущества Явы по скорости — это спекуляция...
При желании и наличии ресурсов (sic!) код на С++ можно оптимизировать так, что любой managed-код будет плестись далеко в хвосте. При сравнениях Java vs C++ vs .NET про возможности оптимизации обычно забывают.
Хотя возможно, что введение генериков в .NET разрыв подсократит — посмотрим, что у них получится

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

Д>Так что преимущества Явы по скорости — это спекуляция...
Д>При желании и наличии ресурсов (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% недостаток в производительности. Увы.)

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

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

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

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

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

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

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

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

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

это был бы просто праздник Ну а пока у них получается на удивление достойный продукт (за вычетом некоторых странностей)... который наверняка займет определенную нишу

Здравствуйте, 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>Которая лишь подтверждает мысль, что ООП везде — это вред и блед, хотя и не отрицает что в бизнес приложениях ООП — это просто круто


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

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

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

Так что проблема не в ООП, а в неверном понимании ООП.

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

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

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

P.S. принимайте все за шутку, как и дурь про чайник.

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

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

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

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

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

и практика эти "заблуждения" прекрасно подтверждает, как ни странно. Обидно, да?

Здравствуйте, Евгений Коробко, Вы писали:

Ну, любезный, у меня Office XP работал на P166MMX, 48 MB RAM. И при этом бытсрее, чем 97. А до этого стоял Office 2000. Он тоже быстрее 97, хотя и медленнее XP. Так что не надо — сначала проверяйте, а потом слова собеседника сомнению подвергайте!

Вы, люди, как обычн опоняли все буквально... Жаль вас, недалеко ушли
Имеется в виду (по сюжету он это рассказывает через N лет после запуска всех этих классов в работу), что когда библиотека классов разрастается (не как STL , а тысячи раз больше), то ты или вообще не имеешь доступа к исходному коду тех первоначальных объектов, либо разбирательство с ними займет ОЧЕНЬ много времени. Там шлось про какие-то очень адвансовые пакеты управления киберами или что-то в таком духе. Это тебе не строчки копировать Писалось все это не одним поколением программеров, так что переделать это — без шансов — там диаграмма иерархии на 900 гиг будет, а исполняются эти проги на сотнях параллельных процессоров (это у самы хпримитивных экземляров) . А вот брать и юзать готовые объекты и, если надо, добавлять в них новую функциональность,- это пожалуйста. Ну не знаешь ты, что этот объект отнаследован в 965 колене от другого, у которого можно немного изменить нужный метод. Пост был о том, что когда библиотека большая и тебе дейтсвительно надо ее расширить (не потратив полжизни на изучение ее структуры ), то возникает проблема того, что ты не знаешь, как оно работает. Вот это автор и хотел показать. В этом и есть проблема ООП, а не в том, что это медленнее функционального программирования на С

Здравствуйте, Hacker_Delphi,


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

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

это даже наверное и верно... мина с часовым механизмом
а когда рванёт?

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

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

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

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

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


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

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


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

полноценным ОО инстурментом считается тот, который пердоставляет возможности разработки
с использование наслед, инкапс, полиморф, создания классов, сериализацию, многопоточность,
и еще кое что. таковым является, например, ява.

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


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


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

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

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

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

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

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

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

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

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

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

Здравствуйте, dad, Вы писали:
dad>нет именно определения классов, поскольку создавать объекты класса ты можешь и в явескрипт
в javascript классов нет. Там только объекты.

Здравствуйте, Ведмедь, Вы писали:

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

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

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

Это пальцем в небо. Еси процедура написана, то нихрена ты с ней не сделаешь. Если программа написана, тож самое. Куда ни ткни, то все парадигмы отстойные. Пишется всягда то, что надо в лижайшем и немного отдаленном удущем. Как написать нечто на все случаи жизни знает только великий Джа. Я так не умею.

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

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

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

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

разработка с использованием наследования = создание (написание ) классов
наверно руками или с помощью RAD?

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

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

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

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

В этом и есть проблемма больших библиотек.

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

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

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

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

да действительно — наседование неотъемлемая часть возможносити создания классов