Re[13]: преимущества неуправляемого С++ - Философия программирования

Здравствуйте, Sergey J. A., Вы писали:

SJA>Здравствуйте, S.Yu.Gubanov, Вы писали:

Ael>>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ael>>>Спасибо!

SYG>>А противоположную по смыслу ссылку не желаете?

SJA>Давай. Кто-нибудь да пожелает. Я например....

А далеко ходить и не надо, вон прямо в соседней ветке...
Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.

http://www.rsdn.ru/Forum/Message.aspx?mid=725451&only=1
SYG>Теперь, собственно, при чем тут сборщик мусора. Рассмотрим более общую ситуацию. Пусть есть многомодульная система. Большинство модулей на момент написания не имели никакого представления друг о друге. Модули — единицы компиляции и исполнения программы, они могут динамически загружаться/выгружаться во время работы Программы. Под Программой, можно понимать всю операционную систему, а модули — ее расширения. Модули создают внутри себя объекты и в виде полиморфных переменных передают их для использования другим модулям, те модули, в свою очередь, могут передать эти полиморфные переменные третьим модулям и т.д.. Модуль создавший обьект и отдавший его другому модулю в принципе понятия не имеет кто еще пользуется этим объектом и как долго он это намерен делать. А значит модуль-создатель в принципе не может нести ответсвенность за уничтожение им созданного объекта. Но никакой другой модуль тоже в принципе не может нести ответсвенность за уничтожение чужого объекта. Подсчет ссылок на объект проблемы не решает поскольку, в общем случае, возможны замкнутые петли (циклические) ссылки объектов друг на друга. Утечка памяти в многомодульных системах неизбежна по принципиально неразрешимым причинам. Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.

http://www.rsdn.ru/Forum/Message.aspx?mid=735774&only=1
SYG>Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.

http://www.rsdn.ru/Forum/Message.aspx?mid=737312&only=1
SYG>Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям?
SYG>В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?

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

K>Бред сивой кобылы. Взять к примеру Catia (это CAD такой) имеет модульную (компонентную) архитектуру. Причем состоит не из нескольких компонентов, а скорее из нескольких сотен. Написан на С/С++

K>О... Маразм крепчал.

K>Это бред не могу себе представить. Если и есть такая система то как правило загружаемые модули редко общаются друг с другом. Например плагины даже и не знают о существовании друг друга. Т.е. такой пробелемы нет в природе. А если там действително все друг на друге заявзано причем модули разных производителей то такую систему и написать-то будет очень проблемматично, т.к. врядли удасца связать все это вместе. Как правило такие системы имеют древовидную архитектуру. Т.е. к ядру подрубаются плагины, и к плагинам подплагины и т.п.

K>Тот кто написал этот бред наверное и не видел больших систем-то. Даже если и есть такие системы (где все друг на друге) то это мертворожденнные проекты. т.к. такое очень сложно поддерживать и развивать и место ему только на мусорке.

K>Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.

Уважаемый, Ваша реакция неадекватна. Я допускаю, что Вы не вкурсе, что термины "модульность" и "компонент" в рамках компонентно ориентированной парадигмы программирования предложенной Клеменсом Шиперски десять лет назад имеют чуточку не тот смысл что использовали Вы охарактеризовав так программу написанную на С++. Я допускаю что Вы не вкурсе, что уже десятилетие как существуют модульные операционные системы (разные клоны Оберонов). Я допускаю, что Вы не вкурсе того как можно проектировать большие модульные системы и поэтому сомневаетесь в возможности этого: "такую систему и написать-то будет очень проблемматично", "это мертворожденнные проекты". Так же я допускаю, что Вы не вкурсе того что ноги .NET, Java, Inferno+Limbo растут из копирования академически грамотных систем — Оберонов. Я допускаю, что Вы не понимаете почему в модульных системах всегда есть сборщик мусора. Но если Вы этого не знаете или не понимаете, то почему бы Вам вместо того чтобы кидаться словами — "Бред сивой кобылы", просто по человечески спокойно поинтересоваться о том что не знаете?

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>[OffTopic]
SYG>Ну, блин, прямо рабовладельческий строй. Даешь демократию!

SYG>[/OffTopic]
Как!? Вы не верите в американскую демократию?
Тогда мы летим к вам!

... << RSDN@Home 1.1.3 beta 1 >>

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

AVK>Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.

Слышал такое "Бытие определяет сознание"? GC это как бы новый вид бытия который определяет новый вид сознания — пофигисты. Люди которым пофиг когда и что освободится.
Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет

Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
GC прививает плохой стиль работы с ресурсами вообще. Мозги у человека одни, а не 20. И помнить что надо освобождать все ресурсы проще, чем помнить что надо освобождать все кроме памяти.
using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.
Я тоже процитирую IT, ты не против?

http://rsdn.ru/article/dotnet/GCnet.xml

абзац выше +

Похоже, using появилась в языке перед самым его выходом, по крайней мере, ничего подобного нет больше ни в одном другом языке, поддерживающем CLR. Да и в мегабайтах исходного кода, который предоставила Microsoft как CLI, эта конструкция встречается всего пару раз, в то время как её аналог в виде try/finally сплошь и рядом. К тому же в статьях Джефри Рихтера об алгоритмах работы GC, которые были опубликованы полтора года назад в MSDN Magazine и которые затем аккуратно в полном объёме перекочевали в его книгу, нет никакого упоминания о using. В самой же книге этому уже посвящён целый небольшой раздел. Вряд ли человек, который имеет неограниченный «доступ к телу», включая самые интимные места, не знал об этом ранее.

То есть из-за GC который вроде бы должен автоматически освобождать ресурсы возникла дикая проблема освобождать их вовремя. Более того, где гарантия что я догадаюсь напистаь using? А если я использую чужой класс? откуда мне знать нужен здесь Unsing или нет? Выходит забота о своевременном освобождении ресурсов опять ложится на программиста, тогда как задача освобождения памяти (но не всех ресурсов) решена.

ИМХО тот GC который в .Net больше похож на заплатку, чем на здравое решение. Освобождать только память смешно. MS мог бы подсуетится и сделать что-то хотя бы для для Kernel Objects (те которые HANDLE).

Я соглашусь, что в 90% случаев единственный используемый ресурс это память, но остальные 10 не дают мне спать спокойно

AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

Однако на практике их путать приходится

Что-то мало я видел полезных программ где из ресурсов используется только память.

AVK>А вот парсер R#, использующий System.String не останавливается.

Это потому что исходники пока маленькие

AVK>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

ИМХО вредный. Он не только не решает задачу в целом, но и создаёт дополнительные трудноуловимые проблемы.
Вот если бы объекты уничтожались как только перестануть быть нужны, или по крайней мере можно было пометить объект каким нибудь dispnowait (свойство передавалось бы наследникам и контейнерам) было бы намного лучше.
А так старые проблемы с плеч программиста убрали, новые полодили.

О других преимуществах .Net и C# таких как метаинформация и проч. я не спорю, так как это действительно хорошо.

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

mdw>>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релИгиозную

То есть тебе показалось мало оверквотинга в первом посте и ты решил увеличить его вдвое?

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Здравствуйте, Sergey J. A., Вы писали:

SJA>>Здравствуйте, S.Yu.Gubanov, Вы писали:

Ael>>>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ael>>>>Спасибо!

SYG>>>А противоположную по смыслу ссылку не желаете?

SJA>>Давай. Кто-нибудь да пожелает. Я например....

SYG>А далеко ходить и не надо, вон прямо в соседней ветке...
SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.

Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе.
И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.
Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?
Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?

Нечто подобное лет 8 назад уже проходилось слышать от "старых unix-оидов", которые использовали свои подходы к написанию мелких утилит при серверных серверных или просто интерактивных приложений

и в итоге создавали немало проблем и бессонных ночей своим коллегам по комманде.

Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А далеко ходить и не надо, вон прямо в соседней ветке...
SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.

Бред сивой кобылы. Взять к примеру Catia (это CAD такой) имеет модульную (компонентную) архитектуру. Причем состоит не из нескольких компонентов, а скорее из нескольких сотен. Написан на С/С++

SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=725451&only=1
SYG>>Теперь, собственно, при чем тут сборщик мусора.
/*поскипано*/

О... Маразм крепчал.

SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=735774&only=1
SYG>>Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.

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

Тот кто написал этот бред наверное и не видел больших систем-то. Даже если и есть такие системы (где все друг на друге) то это мертворожденнные проекты. т.к. такое очень сложно поддерживать и развивать и место ему только на мусорке.

SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=737312&only=1
SYG>>Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям?
SYG>>В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?

Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).

SYG>Архитектура — это одно, а ссылки между объектами — это другое. Архитектура — это то как модули друг друга импортируют.Модули всегда друг друга импортируют без циклов, стараются конечно — древовидно, но это не обязательно, главное что циклически модули не умеют импортироваться. А ссылки между объектами во время выполнения программы могут быть произвольные хоть циклические, хоть сами на себя — эти связи диктуются не архитектурой программы, а предметной областью для которой была написана программа. Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.

И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов"

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

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

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

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

R>>Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе.
R>>И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.

AVK>Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.

ОК, переформулируем — если речь идет об ООП то программа должна явно управлять циклом жизни (lifecycle) любого обьекта который она создала и в нужный момент явно его удалить.
GC во первых — просто развращает, во вторых делает вообще невозможным поиск Memory leak-ов путем автоматическог анализа кода и очень сильно затрудняет их поиск путем Code Review.

R>>Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?
AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).
Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.
Более того, не всегда есть возможность знать заранее в каком случае "Память больше не ресурс", а когда обьект/некоторые его части были созданы на внешнем сервере, и позволить GC решать, когда он будет освобожден это непозволительная роскошь.
Даже когда разработчик исползует jdbc, он вполне может не знать, будет ли незакрытый RecordSet просто Memory leak-ом на 20kb в java машите, который исправит GC, или незакрытым курсором в БД, который "весит" десятки мегабайт.

R>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
AVK>А вот парсер R#, использующий System.String не останавливается.

Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.

R>>Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.

AVK>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью", но когда такая возможность предоставляется самой технологией, и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.
Например в Java я предпочел бы возможность решать в каждом отдельном случае делать "delete a" или "System.manageLifeTime(a)".

Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать, а в обратных случаях часто возникают большие проблеммы.

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

SYG>>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.

D>Ааафигеть можно! Как же многоуважаемый сэр объясняет существование операционной системы Windows, и таких продуктов как Microsoft Office?

Афигейте, мне то что. А, собственно, что именно надо объяснить? Я разьве говорил что кроме модульных систем никаких других систем не бывает? Конечно бывают как модульные так и не модульные системы, вот, пожалуйста, тот же Windows с Unix-ом не модульные и ничего вроде, нормально работают.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=744961&only=1
SYG>демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".

Почему же кривой все верно написано. Вы предложили избавится от класса Абстрактный агрегат, но чтобы от него избавится необходимо в каждом классе продублировать его функционал. Т.е в каждом классе прийдется иметь список жен детей отцов и матерей. Т.е. посути либо копи-пасте, либо делаем общий базовый класс. Но общий базовый класс делать бесмысленно т.к. нет смысла держать копию агрегата в каждом классе. Действительно представте себе машину в которой каждая деталь сдержит всю машину (вернее копию ссылок на все агрегаты). Имхо это криво не подецки. Гораздо лучше иметь агрегат как отдельный обьект а в нем уже содержать все необходимые ссылки. И в каждом обьекте ссылка на агрегат. Так будет проще и лучше в любой системе независимо есть там сборщик мусора или нет.

ЗЫ. А то что вы написали про экономию на одном классе то поверьте мне на слово (или проверьте) что можно сэкономит гораздо больше простым переходом от BEGIN-END к {}

ЗЫЗЫ: А если серьезно то рекомедую попрограммировать годика три для начала в реальном комерческом проекте. Это очень поможет.

ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.

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

Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ты немного не "с той стороны" смотришь. C++ — язык. .Net или Java — среды со своими языками. Их сравнивать вообще нельзя. И нельзя будет впредь. Разве что так: C++ — трудный, а Java с библиотеками или .Net — сложные, но в принципе — нетрудные вещи.

Если тебе нужно определить — стоит ли изучать C++, то по крайней мере мой ответ — положительный. После него станет ясно — откуда у чего ноги растут в "современных" системах программирования. Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.

Ael>Спасибо!
Да пожалуйста.

SYG>Афигейте, мне то что.
Да я офигеваю, офигеваю...

SYG>А, собственно, что именно надо объяснить?
Не надо ничего обяснять, я уже все понял.

SYG>Я разьве говорил что кроме модульных систем никаких других систем не бывает? Конечно бывают как модульные так и не модульные системы, вот, пожалуйста,
SYG>тот же Windows с Unix-ом не модульные и ничего вроде, нормально работают.
Вот только не надо валить в одну кучу современные Windows системы и технологию тридцатилетней давности.
-----------------------------------------------------

А теперь вернемся к вопросу модульных систем.

SYG>>Теперь, собственно, при чем тут сборщик мусора.
Вообще говоря, ни при чем.

SYG>>Пусть есть многомодульная система.
Windows

SYG>>Большинство модулей на момент написания не имели никакого представления друг о друге.
Ну это вряд ли, иначе что они будут друг с другом делать?

SYG>>Модули — единицы компиляции и исполнения программы, они могут динамически загружаться/выгружаться во время работы Программы.
COM servers.

SYG>> Под Программой, можно понимать всю операционную систему, а модули — ее расширения.
COM client (пусть это будет пронрамма, просто программа).

SYG>>Модули создают внутри себя объекты и в виде полиморфных переменных передают их для использования другим модулям,
COM objects.

SYG>>те модули, в свою очередь, могут передать эти полиморфные переменные третьим модулям и т.д..
А захотят ли?

SYG>>Модуль создавший обьект и отдавший его другому модулю в принципе понятия не имеет кто еще пользуется этим объектом и как долго он это намерен делать. А значит модуль-создатель в принципе не может нести ответсвенность за уничтожение им созданного объекта. Но никакой другой модуль тоже в принципе не может нести ответсвенность за уничтожение чужого объекта.
И не надо. Объект сам знает, когда ему убиться.

SYG>>Подсчет ссылок на объект проблемы не решает поскольку, в общем случае, возможны замкнутые петли (циклические) ссылки объектов друг на друга.
А вот для избежания циклических зависимостей в COMе существуют такие механизмы как Connection points. Anyway, циклические зависимости возникают как правило в сильно связанных объектах, т.е. в границах одного-нескольких модулей, да и то по ошибке автора.

Ну и чем вам Windows не модульная система?

SYG>>Утечка памяти в многомодульных системах неизбежна
SYG>>по принципиально неразрешимым причинам.
Хотелось бы ознакомиться с ними.

SYG>>Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
Не понял, откуда это следует.

... << RSDN@Home 1.1.3 stable >>

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

SYG> На обычном С++ модульные программы писать невозможно.
VD>Ну, ну, так уж не невозможно.

Приношу свои извинения. Эту мою фразу прошу понимать так: "Язык С++ не поддерживает модульное программирование, и компонентно ориентированную парадигму программирования тоже не поддерживает".

VD>Тяжело — да. Но КОМ пока никто не отменял.

Упс-с-с, а про КОМы, это сюда:

SYG>По поводу COM-ов:
http://www.rsdn.ru/Forum/Message.aspx?mid=739058&only=1

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Я допускаю что Вы не вкурсе, что уже десятилетие как существуют модульные операционные системы (разные клоны Оберонов).

SYG>Я допускаю, что Вы не вкурсе того как можно проектировать большие модульные системы и поэтому сомневаетесь в возможности этого: "такую систему и написать-то будет очень проблемматично", "это мертворожденнные проекты".

Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).

SYG>Так же я допускаю, что Вы не вкурсе того что ноги .NET, Java, Inferno+Limbo растут из копирования академически грамотных систем — Оберонов. Я допускаю, что Вы не понимаете почему в модульных системах всегда есть сборщик мусора. Но если Вы этого не знаете или не понимаете, то почему бы Вам вместо того чтобы кидаться словами — "Бред сивой кобылы", просто по человечески спокойно поинтересоваться о том что не знаете?

Люди которые делали НЕТ и Яву — практики с огромным опытом и с огромным числом набитых шишек и со знанием подводных камней и течений, им до этих академических поделок просто нет никакого дела. Более того академические поделки как правило не выдерживают проверки на практике. Сразу обнажается куча непонятно откуда взявшихся проблем в дизайне, недостатков и т.д. и т.п.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.

... << RSDN@Home 1.1.3 beta 1 >>

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

D>Согласен, но это никак не опровергает мое мнение, а дополняет его.

Ваш спор терминологический. Просто ты вкладваеш один смысл, а он другой.

D>Можно подумать, я не писал COM-объектов. С++ можно использовать на полную катушку, сделав всего две вещи — унаследоваться от IUnknown, и правильно его имплементировать.

А что такое сам IUnknown? Зачем он если язык поддерживает компонентность.

Вот чистый код на шарпе:

interface I1
{
    int Method();
}

interface I2
{
    int Method();
}

clas A : I1, I2
{
    int I1.Method() { return 1; }
    int I2.Method() { return 2; }
}

calss Test
{
    static void Main()
    {
        I1 i1 = new A();
        int i =   i1.Method(); // i == 1
        i = ((I2)i1).Method(); // i == 2
        I2 i2 = (I2)i1;
        i = i1.Method(); // i == 2
    }
}

Заметь, ничего лишнего. Код чист и красив. Попробуй изобразить тоже самое на С++ и сравни результат. Объем кода, его чистоту. Они несравнимы даже если отбросить все библиотеки (куча кода по регистрации, разные мапы и т.п.). А уж если сравнить со всей подноготной, то все будет просто смешно.

Особенно некрасиво выглядит приведение через QI. Вся типобезопасность языка идет лесом.

D> А то, что плюсы — это бесконечное поле засеянное граблями известно всем.

Похоже не всем. Тут постоянно идут споры о крутизне плюсов. Собственно я не против того, что язык мощный. И что для некоторых задач ему до сих пор нет равных. Но возведение его в ранг божественных явный перебор.

VD>>1. Наличие не виртуального публичного интерфейса.
D>Это проблема?

Да. Как минимум производительность страдает.

D>И как COM должен получать адреса функций без vtlb?

Это его проблемы. В дотнете эта проблема решена.

VD>>2. Множественное наследование.
D>Во-первых, это общепризнанный источник неприятностей

.

И тем не мнее это одна из ключевых фич языка. Без нее фиг бы ты получил все прелисти того же АТЛ. Ну, и многие боготворят ее.

D> Во-вторых, я не вижу применимости множественного наследования от _чужих_ компонентов. Для компонентов/объектов в одном проекте никто не мешает им пользоваться.

Есть язык мощный своими фичами. И есть их невилирование когда речь заходит о компонентности. Факт?

VD>>3. Приведение типов.
VD>>4. Создание объектов.
VD>>5. Импорт типов.
D>Вот эти пункты я совсем не понял.

QI подменяет стандартные способы приведения типов. CI заменяет оператор new. Тлб и их импорт заменяет хэадеры. На лицо издевательство над славным языком. От языка камня на камне не осталось. Все положено на алтарь компонентности. Ну, и как результат отключение проверок типов языка (в QI и CI можно подсунуть любой указатель, один фиг к воиду приводить).

VD>>В общем, пол языка заменяется сурогатами. В том же дотнете компонентность встроена в языки и выглядт так как будтно это часть языка.
D>Так за это и боролись.

Ну, вот о том и речь. Поддержки компонентности в С++ просто нет по сравнению с тем же Шарпом.

D>Я совершенно не собираюсь доказывать, что C++ — идеальный язык для компонентно-ориентированного программирования. Это не так. Но и в обиду его не дам.

Я в доволь натрахался делая КОМ-объекты на АТЛ. И перйдя на дотнет я имею намного больше с практически нулевыми усилями. Теперь чтобы заставить мнея сделать КОМ-объект на плюсах нужно очень постараться. Вот об это и речь. Думаю твоей аппонент как раз и пытался донести эту мысль. Ну, чутка пергнул палку.

... << RSDN@Home 1.1.4 beta 2 >>

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

WH>

Есть объект граф. Есть объект вершина графа. Граф владеет вершинами. Если убить граф то то он убьет вершины ибо он их владелец. Следовательно вершины могут как угодно ссылатся друг на друга от смерти в нужный момент это их не спасет. Врешина одного графа ссылающаяся на вершину другого графа есть ошибка ибо это не имеет смысла. Интерфейс графа не должен допускать такой возможности. Без объекта граф в общем случае обойтись нельзя ибо ни кто не отменял не связанные графы и тем болие ориентированные.

А если этот Граф, нечаянно проболтается кому-нибудь внешнему о своих вершинах (сообщит кому-нибудь адрес объекта-вершины). Тогда ему, когда придет время умирать, уже нельзя будет удалить ни эту вершину, ни какую другую о которой та вершина была осведомлена. Ведь он понятия не имеет о том внешнем — работает оно с этой вершиной или больше не работает...

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

K>>И где в этом примере циклические ссылки? и проблемма с ними?

B>родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
B>эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий

B>аналог ссылки — днк

Неверно. По ссылке можно удалить обьект, передать его куда нибудь (в функцию) или изменить (вызвать метод). А по днк что можно сделать? Эти аналогии сдесь не работают

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

K>Я подозреваю что GC-шные программы будут падать реже, но зато будут полны разными трудноуловимыми глюками.

Как показывает практика твои подозрения не соответствуют действительности.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>"Тиединый объект" все-таки конечно лажа, но вот "Абстрактный Агрегат", кажись рулит:
SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=743628&only=1

О! Чувствуется академическая закалка: абстрактый агрегат, абстрактный пример, абстрактный язык, абстрактая сиистема, абстрактный вывод...

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

AVK>>Оттуда что выделения памяти в программе как правило как минимум на порядок больше, чем выделения неуправляемых ресурсов.
VD>Порядок — это не смешно. 3-4 порядка будет ближе к истене. Я тут глянул сколько юсингов в парсере... так вот один. А сколько там выделений памяти пожешь себе представить.

А сколько там сейчас глюков и недоделок даже представлять не хочется

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

Ael>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой, хотя конечно очень интересно. Но получить четко сформулированное обоснование подобных усилий было бы неплохо.
Лучше всего почитать первоисточник: Страуструп. Дизайн и эволюция С++. Там мэтр рассказывает, почему и как С++ получился таким — с самого начала и до появления STL. Очень интересное повествование.

SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.

Ааафигеть можно! Как же многоуважаемый сэр объясняет существование операционной системы Windows, и таких продуктов как Microsoft Office?

... << RSDN@Home 1.1.3 stable >>

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

Ael>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой,

С++ конечно штука сложная, но C# вряд ли сильно проще, скорее наоборот, сложнее.

... << RSDN@Home 1.1.4 beta 2 >>

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

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

Ael>>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой,

AVK>С++ конечно штука сложная, но C# вряд ли сильно проще, скорее наоборот, сложнее.

Обоснуйте, пожалуйста, какие критерии сложности вы используете?
Когда я говорю, что С# для меня проще, я руководствуюсь тем, что после аналогичного периода изучение языка я мог создавать на С# (и на управляемом С++) гораздо более продвинутые приложения, чем я сейчас могу на на неуправляемом С++.
MSDN документация по .NET Framework читается гораздо легче, чем MSDN документация по С++.
При сравнении языков очень трудно дистанцироваться от платформ — опять же контейнеры STD кажуться мне гораздо сложнее, чем System.Collections;
Итак какие критерии сложности?

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

Ael>Обоснуйте, пожалуйста, какие критерии сложности вы используете?

Для начала нужно обосновать какие критерии исползовались в заявлении выше.

Ael>Когда я говорю, что С# для меня проще, я руководствуюсь тем, что после аналогичного периода изучение языка я мог создавать на С# (и на управляемом С++) гораздо более продвинутые приложения, чем я сейчас могу на на неуправляемом С++.

Это говорит о качествах языка, но не о его сложности.

Ael>MSDN документация по .NET Framework читается гораздо легче, чем MSDN документация по С++.

Ну, это вообще разговор о документации. Языки тут точно не причем.

Ael>При сравнении языков очень трудно дистанцироваться от платформ — опять же контейнеры STD кажуться мне гораздо сложнее, чем System.Collections;
Ael>Итак какие критерии сложности?

Да не надо сравнивать языки с платформами. Это же просто глупо! Ты же не станешь сравнивать грузовой автомобиль с автопромышленностью? А почему для тебя наормально сравнивать платформу с одним из реализованных на ней языков?

Что же касается сложности, то тут все зависит от того, что понимается под этим термином. С++ несомненно сложный язык. Он сложен в изучении и применении. Но с точки зрения формальной граматики и поддерживаемых фич — это очень простой язык. В нем нет и половины конструкций того же Шарпа. В нем нет даже модульности и вообще каких бы то нибыло мыслей о компиляции и рантайме (все заканчивается на ЦРТ и инклюдах).

ЗЫ

Исходя из всего этого:
1. Сравнивать можно только языки.
2. Нужно четко определять что понимается под сложностью.
3. Разумно говорить о недостатках и приемуществах, а не о тотальном превосходстве. Все же работать с БД на С++ — это такой же мазохизм, как пытаться писать драйверы на Шарпе.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>Что же касается сложности, то тут все зависит от того, что понимается под этим термином. С++ несомненно сложный язык. Он сложен в изучении и применении. Но с точки зрения формальной граматики и поддерживаемых фич — это очень простой язык. В нем нет и половины конструкций того же Шарпа. В нем нет даже модульности и вообще каких бы то нибыло мыслей о компиляции и рантайме (все заканчивается на ЦРТ и инклюдах).
Повторю еще раз язык одной грамматикой не ограничивается. Тем болие что та грамматика что в стандарте и близко не описывает С++. В этой ветке вобще пытаются доказать что грамматика С++ контекстно свободная

Вот взять хотябы R# на сколько я знаю ты рание не имел дела с компиляторами но смог создать C# фронтенд соответствующий стандарту. А теперь давай вспомним про то что не существует ни одного С++ фронтенда соответствующего стандарту. Даже в EDG ошибки находят и микрософт со своими миллиардами не может довести VC++ до стандарта.
Короче твои заявления о том что C# сложнее С++ до того как ты напишешь С++ фронтенд полностью соответствующий стандарту идут лесом.

VD>3. Разумно говорить о недостатках и приемуществах, а не о тотальном превосходстве. Все же работать с БД на С++ — это такой же мазохизм, как пытаться писать драйверы на Шарпе.
Вот с этим в принципе согласен. Хотя работать с БД на плюсах не такой уж и мазахизм.

... << RSDN@Home 1.1.3 beta 1 >>

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

WH>Вот взять хотябы R# на сколько я знаю ты рание не имел дела с компиляторами но смог создать C# фронтенд соответствующий стандарту. А теперь давай вспомним про то что не существует ни одного С++ фронтенда соответствующего стандарту. Даже в EDG ошибки находят и микрософт со своими миллиардами не может довести VC++ до стандарта.

Дык это только говорит, о непродуманности стандарта. И о том, что он не во всем отвечае рельным потребностям.

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

WH>Короче твои заявления о том что C# сложнее С++ до того как ты напишешь С++ фронтенд полностью соответствующий стандарту идут лесом.

А мне сдается, что твое условия идут лесом.

Граматику С++ я хорошо изучил. Нет там ничего сложного. Вот в разрешении имен там каша. А граматика простая.

VD>>3. Разумно говорить о недостатках и приемуществах, а не о тотальном превосходстве. Все же работать с БД на С++ — это такой же мазохизм, как пытаться писать драйверы на Шарпе.
WH>Вот с этим в принципе согласен. Хотя работать с БД на плюсах не такой уж и мазахизм.

Да, такой. За то время пока ты на плюсах будешь все МС-ные кракозябры от КОМ-объектов разбирать, я на шарпе уже приложение допишу. А R# доведем до ума, и во многих других областях смысла в плюсах не будет.

ЗЫ

Ты кстати, подмогнеш нам на поприще языкостроения или уже передумал?

... << RSDN@Home 1.1.4 beta 2 >>

SYG>По поводу COM-ов:
SYG>Я сказал что Windows не модульная система и еще сказал что под Windows нельзя писать модульные программы.
SYG>Вы удивились и спросили, а как же тогда COM? Не беспокойтесь, все очень просто. Дело в том что среда Win32 и среда COM — разные вещи. Среда COM существует поверх среды Win32, точно также как среда BlackBox от Oberon Microsystems тоже существует поверх среды Win32.
OK. Будем понимать под Windows не только ядро системы, но и COM. На COMе нельзя делать модульные программы? COM нельзя использовать в С++? COM, да и Windows вообще имеет какое-то отношение к языкам программирования?

SYG>Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET".
Нельзя.

SYG>Цитата:
SYG>"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32"
SYG>Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз.
Написали два чувака глупость. Теперь все будем повторять?

Вы бы тоже признались, что сморозили глупость и дело с концом.

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

D>>Не понял, откуда это следует.

SYG>На примерах чтоли объяснять?
Такое сильное заявлений хорошо бы поддержать чем-то более серьезным (академичным, я б сказал

).
Примеров не надо — я циклические зависимости разрываю силой воли. К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.

... << RSDN@Home 1.1.3 stable >>

Ну хорошо. Я согласен с новой формулировкой заяввления о C++ и модульном программировании. C++ позволяет делать несовместимые с ним вещи, но писать на С++ модульные программы можно, выполняя определенные правила.

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

Да, если система не желает полагаться на выполнение правил разработчиками компонентов, единственным средством контролировать время жизни объектов остается общесистемный GC.

А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.

... << RSDN@Home 1.1.3 stable >>

VD>Ну, кроме правил у КОМ был еще рантайм и разные фичи типа мидл-а и тлб.
VD>Все вместе это называется технологией. В принципе базовые вещи можно делать и без КОМ-а или его аналогов. Но траху несоизмеримо больше.
Согласен, но это никак не опровергает мое мнение, а дополняет его.

VD>По этому можно смело заявлять, что С++, как язык, не поддерживает компонентную разработку. И компоненты на нем можно делать не благодаря его возможностям, а вопреки им.
Можно подумать, я не писал COM-объектов. С++ можно использовать на полную катушку, сделав всего две вещи — унаследоваться от IUnknown, и правильно его имплементировать. А то, что плюсы — это бесконечное поле засеянное граблями известно всем.

VD>Вот список фич С++ которые КОМ намеренно отключает, запрещает и подменяет своей реализацией:

VD>1. Наличие не виртуального публичного интерфейса.
Это проблема? И как COM должен получать адреса функций без vtlb?

VD>2. Множественное наследование.
Во-первых, это общепризнанный источник неприятностей

. Во-вторых, я не вижу применимости множественного наследования от _чужих_ компонентов. Для компонентов/объектов в одном проекте никто не мешает им пользоваться.

VD>3. Приведение типов.
VD>4. Создание объектов.
VD>5. Импорт типов.
Вот эти пункты я совсем не понял.

VD>В общем, пол языка заменяется сурогатами. В том же дотнете компонентность встроена в языки и выглядт так как будтно это часть языка.
Так за это и боролись.

Я совершенно не собираюсь доказывать, что C++ — идеальный язык для компонентно-ориентированного программирования. Это не так. Но и в обиду его не дам.

... << RSDN@Home 1.1.3 stable >>

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

K>Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).

SYG>>Архитектура — это одно, а ссылки между объектами — это другое. Архитектура — это то как модули друг друга импортируют.Модули всегда друг друга импортируют без циклов, стараются конечно — древовидно, но это не обязательно, главное что циклически модули не умеют импортироваться. А ссылки между объектами во время выполнения программы могут быть произвольные хоть циклические, хоть сами на себя — эти связи диктуются не архитектурой программы, а предметной областью для которой была написана программа. Если программа, например, написана для работы с графами, то понятно, что объекты этой программы ссылаются друг на друга так как в том графе нужно, к архитектуре же это отношения не имеет.

K>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов"

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

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

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

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

K>>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов"

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

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

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

Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.

И где в этом примере циклические ссылки? и проблемма с ними?

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

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

K>>>И где здесь проблемма в сылках между обьектами? Возьмите реальную жизнь — человеческое тело: почки, печень и т.п. на своих местах и в никаком сборщике мусора не нуждаются. Сборшик мусора прийдет в конце один для всех "обьектов"

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

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

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

K>Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.

K>И где в этом примере циклические ссылки? и проблемма с ними?

дополнение
ссылка=днк передается другой особи при спаривании и что произойдет в дальнейшем с твоей личной наследственной информацией неизвестно, она тебе неподконтрольна

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

AVK>>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.

D>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.

А при чем тут GC?

D>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.

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

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

SYG>А если этот Граф, нечаянно проболтается кому-нибудь внешнему о своих вершинах (сообщит кому-нибудь адрес объекта-вершины). Тогда ему, когда придет время умирать, уже нельзя будет удалить ни эту вершину, ни какую другую о которой та вершина была осведомлена. Ведь он понятия не имеет о том внешнем — работает оно с этой вершиной или больше не работает...

Логика неверна. Если разделяемым объктом (т.е. имеет несколько владельцев) является граф, то висящая ссылка на вершину — это неверный дизайн. Когда нужно будет удалить граф то он останется в памяти из-за этой ссылки. Т.е. ресурс не будет освобожден и в этом случае от GC вреда больше чем пользы. Более того возможно непредсказуемое поведение из-за того что граф как-бы удален, а вершина осталась.

А в случае если вершина является разделяемым обьектом, а граф ее просто использует то здесь как разе нет проблемм, граф умирает и каждой вершине делает release или detach_form_graph и т.п. в зависимости от контекста.

Т.е. проблема не в ссылках или GC, а в дизайне(головах).

И более того в сложных случаях когда все друг на друге завязано гораздо лучше ручное управление памятью, например геометрическая модель: обьект один — тело, но состоит из целой кучи edges,faces,nodes,bounds,curves,surfaces,vertices,triangles и куча всяких прокешированных данных и все циклично ссылается друг на друга. Если я накрыл тело то висящая сылка в программе к примеру на face — откровенно неверный дизайн. Более того когда память освобождается ручками, то при обращении к этой ссылке будет лекго обнаружимая ошибка, а если все это барахло (из-за) подвисшей ссылки удерживается GC в памяти, то это самое настоящее проклятье. Все может тихой сапой отработать, однако ошибку попробуй найди.

Я подозреваю что GC-шные программы будут падать реже, но зато будут полны разными трудноуловимыми глюками.

В любом случае тонкая, ручная и профессиональная работа на С++ всегда будет в цене.

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

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

K>>>И где в этом примере циклические ссылки? и проблемма с ними?

B>>родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
B>>эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий

B>>аналог ссылки — днк

K>Неверно. По ссылке можно удалить обьект, передать его куда нибудь (в функцию) или изменить (вызвать метод). А по днк что можно сделать? Эти аналогии сдесь не работают

мыслите более абстрактно
аналогом модуля является не отдельная живая особь, а генетическая линия

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

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

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

B>мыслите более абстрактно
B>аналогом модуля является не отдельная живая особь, а генетическая линия

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

B>аналогия между воздействием естественного отбора на слабейших представителей видов животных (или же переработка бактериями трупов растений и животных и превращение их в ресурсы для новых поколений организмов) по моему очевидна
B>а более сложную систему (включая сложность строения отдельных ораганизмов) чем экосистема, например тропического леса, по моему невозможно даже представить
B>любая спроектированная человеком система уступает такой на миллионы порядков

И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А если этот Граф, нечаянно проболтается кому-нибудь внешнему о своих вершинах (сообщит кому-нибудь адрес объекта-вершины). Тогда ему, когда придет время умирать, уже нельзя будет удалить ни эту вершину, ни какую другую о которой та вершина была осведомлена. Ведь он понятия не имеет о том внешнем — работает оно с этой вершиной или больше не работает...

То что он нечаянно проболтается — это censored дизигна. Все должно быть параллельно и перпендикулярно — объекты, использующие граф должны умирать раньше него. Или по карйней мере должен быть формализован порядок — кто что удаляет. Это не вопрос языка — это вопрос проектирования системы

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

K>Логика неверна...

Какая логика? Давайте придумает другую логику. Освободим свой разум от стереотипов наложенных отсутствием сборщика мусора.

Вот сейчас пришел в голову такой вариант:

Сначала вариант реализации со счетчиком ссылок

Есть объект, который состоит из 1) модели (предметной области); 2) визуализатора модели 3) редактора модели

Model = INTERFACE
    //.. что-то из предметной области
  END;

View = INTERFACE
    FUNCTION  Model: Model; // Представление осведомлено о модели чтобы уметь ее рисовать
    PROCEDURE DrawTo(G: Graphics);
    //...
  END;

Edit = INTERFACE
    FUNCTION  Model: Model; // Редактор осведомлен о модели чтобы уметь ее редактировать
    FUNCTION  View : View;  // Редактор осведомлен о представлении чтобы уметь рисовать модель
    PROCEDURE Show;         // Создает и показывает форму редактирования объекта
    //...
  END;

Controller = INTERFACE
    FUNCTION  Model: Model; // Контроллер владеет моделью объекта
    FUNCTION  View : View;  // Контроллер владеет представлением объекта
    FUNCTION  Edit : Edit;  // Контроллер владеет редактором объекта
    //...
  END;

Controller — это, собственно сам объект, а Model, View, Edit — это "запчасти" объекта. То есть фактически получается, что один объект из предметной области представлен четырьмя объектами (экземплярами разных классов) из языка программирования.

А теперь тоже самое, но при наличии в системе сборщика мусора:

Теперь никто друг другом не владеет

  Controller = INTERFACE
    FUNCTION  Model: Model;
    FUNCTION  View : View;
    FUNCTION  Edit : Edit;
  END;

  Model = INTERFACE (Controller)
    //.. что-то из предметной области
  END;

  View = INTERFACE  (Controller)
    PROCEDURE DrawTo();
    //...
  END;

  Edit = INTERFACE (Controller)
    PROCEDURE Show;
    //...
  END;

Теперь отдельного класса реализующего интерфейс Controller больше нет. Просто классы реализующие интерфейсы Модели, Визуализатора и Редактора также реализуют и интерфейс Controller-а. То есть классов стало 3 вместо 4-х. Экономия, однако.

        Model----View
          |        |
          |        |
          +--Edit--+

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

  Controller = INTERFACE
    FUNCTION  Model: Model;
    FUNCTION  View : View;
    FUNCTION  Edit : Edit;
  END;

С точки зрения языка программирования не имеющего сборщик мусора такой дизайн триединого объекта является бредом (ни Модель ни Представление, ни Редактор друг другом не владеют, а лишь осведомлены о существовании друг друга, но в качестве самого объекта предметной области можно использовать любого из них). Как только внешняя среда теряет к этому триединому объекту интерес, то сборщик мусора удаляет его во всех его трех ипостасях.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Логика неверна...

SYG>Какая логика? Давайте придумает другую логику. Освободим свой разум от стереотипов наложенных отсутствием сборщика мусора.

SYG>Вот сейчас пришел в голову такой вариант:

SYG>Сначала вариант реализации со счетчиком ссылок
/*поскипано*/

Гы. и зачем так усложнять себе жизнь?
Вот вариант, бес ссылок и сборщиков:

class View {};
class Edit : View {}; // edit - это тоже view

class Controller { // владелец модели и вью-х
    Model            mdl;
    list<View*>    observers; // views-n-edits 
};

// глобальный обьект SDI-приложения
class SDIApp {
    Controller        ct;
    SDIFrame            mainFrame;
} theApp;

// глобальный обьект MDI-приложения
class MDIApp {
    list<Controller*>        cts;
    MDIFrame                    mainFrame;
} theApp;

Все ноги растут из глобального обьекта theApp котроый определяет SDI or MDI интерфейс.
В SDIApp контроллер-часть агрегата (используется повторно via clear()), умирает вместе с theApp.
модель часть контроллера — используется повторно через cleаr(), views умирают вместе с контроллером или при открытии-закрытии. Либо используются повторно в тривиальном случае.

Все просто прозрачно и очевидно. Зачем городить огород? Когда и так ясно кто кем владеет. Когда у нас SDIApp можно еще более "упростить" обьединив контроллер с App, но я против такой экономии т.к. потом трудно будет в MDI переделывать.

Если взять еще более тривиальный случай когда к примеру число едитов и view априорно известно, то можно еще более упростить контроллер:

class Controller { 
    Model    mdl;
    MyView mainView;
      MyEdit mainEdit;
      list<View*>   pluggedViews;
};

Тогда проблемма со ссылками отпадает вообше, т.к. если pluggedViews — всегда пуст, то нет ни одного динамически созданного обьекта верхнего уровня и все обьекты являются частью theApp.

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

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

K>>Я подозреваю что GC-шные программы будут падать реже, но зато будут полны разными трудноуловимыми глюками.

AVK>Как показывает практика твои подозрения не соответствуют действительности.

Думаю пока рано делать выводы. Все "тяжелые" программы (САПРЫ, оффисы и т.п.) которые мы юзаем пока в unmanaged коде.

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

K>Зачем городить огород? Когда и так ясно кто кем владеет.

[OffTopic]
Ну, блин, прямо рабовладельческий строй. Даешь демократию!

[/OffTopic]

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

R>Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе.
R>И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.

Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.

R>Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?

Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

R>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?

А вот парсер R#, использующий System.String не останавливается.

R>Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.

GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

... << RSDN@Home 1.1.4 beta 2 >>

"Тиединый объект" все-таки конечно лажа, но вот "Абстрактный Агрегат", кажись рулит:
http://www.rsdn.ru/Forum/Message.aspx?mid=743628&only=1

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

R>>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
AVK>>А вот парсер R#, использующий System.String не останавливается.

R>Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.

1. Ты тут вроде не на конкретную реализацию ЖЦ бочку катишь. А раз так, то что уж теперь стрелки переводить.
2. Я не раз делал тесты и могу уверенно сказать, что как раз ЖЦ в Яве как минимум не менее эффективен чем в дотнете. Так что это голословные обвинения. А "подвисать" что-то может просто из-за неверно выбранного олгоритма или класса.

R>Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью", но когда такая возможность предоставляется самой технологией, и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.

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

Реалии жизни выглядят совсем иначе. Следить за памятью в приложении просто не нужно. Остается ледить за анменеджед-ресурсами. Чтобы этого не делать выбирается тактика минимального захвата рисурса. Ресурс захаватывается только на время работы функции, а по выходу освобождается. Для автоматизации освобождения используется using. Итого в программе очень редко приходится вообще вспоминать о ресурсах. Ты просто пишешь код, и он работает.

R>Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать, а в обратных случаях часто возникают большие проблеммы.

И какой вывод ты делашь? Я бы сделал вывод, что Ява и Шарп более простые и логичные языки.

... << RSDN@Home 1.1.4 beta 2 >>

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

ГВ>Что-то я не совсем понимаю.

А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?

...

ГВ>Там приведена довольно подробная аргументация по этом поводу. И сказано, кстати, что к GC она не имеет никакого отношения.

Не понимаете? Значит Вам в "сад":
http://www.rsdn.ru/Forum/Message.aspx?mid=743372&only=1

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

ГВ>Да, испытывает.

Например, из-за того, что в finally-блоке нужно прописывать всё то, что можно не писать на языке с детерминированным уничтожением объектов. Отсюда система на Java может оказаться раз 5 больше по объёму, чем аналог на C++.

Но почему-то на практике оказывается в пять раз меньше.

ГВ>

Сдаётся мне, что не всё так просто. ИМХО, нужно освобождать свой разум от заблуждений, что что-то может быть в компьютере "бесплатно".

Сдается мне, что компьютеры тут не причем. Бесплатный сыр бывает только...

ГВ>Что-то я не совсем понимаю.

А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?

В сложности и объеме работ. А так конечно нет проблем. Так же как нет проблем любой софт сделать на ассемблере.

... << RSDN@Home 1.1.4 beta 2 >>

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

K>Но общий базовый класс делать бесмысленно т.к. нет смысла держать копию агрегата в каждом классе. Действительно представте себе машину в которой каждая деталь сдержит всю машину (вернее копию ссылок на все агрегаты).

Там все объяснено (для деталей машин этот паттерн не применим), если Вы что-то не поняли, то пишите возражения там, а не здесь. Зачем в двух ветках обсуждать одно и тоже?

K>ЗЫЗЫ: А если серьезно то рекомедую попрограммировать годика три для начала в реальном комерческом проекте. Это очень поможет.

Согласен. Я пока только 2 года работаю программистом, и за это время много что понял по сравнению со своим начальным уровнем. К концу третьего года пойму еще больше.

K>ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.

Аналогия не говорит о сути предета — она говорит только о том, кто ее привел... © С. Лукьяненко

Не знаю как у Вас, но у меня монолитные архитектуры умещаются в голове только если количество кода не превышает примерно 5'000 строчек кода. Если монолитная система имеет более 10'000 строчек кода, то я психически не выдерживаю и начинаю ее переписывать.

Каковы размеры Ваших монолитных систем?

Что касается характерного размера одного модуля: начинается примерно от 100-200; оптимально — 500 строчек, максимум 2'000 строчек кода.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Не знаю как у Вас, но у меня монолитные архитектуры умещаются в голове только если количество кода не превышает примерно 5'000 строчек кода. Если монолитная система имеет более 10'000 строчек кода, то я психически не выдерживаю и начинаю ее переписывать.

SYG>Каковы размеры Ваших монолитных систем?
Около миллиона строк.

Скорее всего мы по разному понимаем слово монолитная. Монолитная для меня это когда интерфейс не отделен от реализации. Т.е. обычная библиотека классов которая линкуется статически, компонентность предполагает одтеление интерфейса от реализации, т.е. под одним интерфейсом может скрыватся несколько реализаций. Как следствие этого компонентнвй обьект может быть создан только динамически т.к. используемая реализация не известна компилеру-компоновщику, и юзатся он может только через интерфейс. Такой подход во многих случаях просто не нужен. Т.е. можно иметь несколько хорошо спроектированных библиотек классов (которые потихоньку эволющионируют) и на их базе создется программа. Т.к. все линкуется статически получается монолитная архитектура (один экзешник, куда уж монолитнее)

ЗЫ: И ограничений на количество строк в проекте вобщем-то нет.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

SYG>>>Каковы размеры Ваших монолитных систем?
K>>Около миллиона строк.

SYG>Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?

Это как же их учтешь? после развертки? нет обычный код. включая фортрановский.
Компилируется если с нуля минуты три. В релизе поболее.

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

A>ИМХО вредный. Он не только не решает задачу в целом, но и создаёт дополнительные трудноуловимые проблемы.

Все Ваши негодования и возмущения проистекают от попыток использования языков с GC в системах, которые были спроектированы в рамках других идеологий. Если бы операционная система сама была спроектирована от и до в терминах объектно ориентированной идеологии со сборкой мусора, то у Вас бы никогда не возникло псевдопроблем с забытием закрыть файл или другой ресурс ОС. Ни Windows ни UNIX таковыми системами не являются. Таковыми системами являются, например, Обероны...

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

A>Слышал такое "Бытие определяет сознание"? GC это как бы новый вид бытия который определяет новый вид сознания — пофигисты. Люди которым пофиг когда и что освободится.
A>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет

Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.

Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.

A>GC прививает плохой стиль работы с ресурсами вообще. Мозги у человека одни, а не 20. И помнить что надо освобождать все ресурсы проще, чем помнить что надо освобождать все кроме памяти.

Ты пробовал? А да. Не прививает.

A>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.

Ужас? Ты изучал код дотнета? Каким образом?

A>Я соглашусь, что в 90% случаев единственный используемый ресурс это память, но остальные 10 не дают мне спать спокойно

А ты попробуй. Может все не так ужасно?

AVK>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

A>Однако на практике их путать приходится

Расскажи о своей практике.

AVK>>А вот парсер R#, использующий System.String не останавливается.

A>Это потому что исходники пока маленькие

А тебе сколько надо? И для какого языка парсер значительно сложнее?

AVK>>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

A>ИМХО вредный. Он не только не решает задачу в целом, но и создаёт дополнительные трудноуловимые проблемы.

Говорить о вкусе устриц ... Ну ты понял

... << RSDN@Home 1.1.4 beta 2 rev. 152>>

AVK>>А вот парсер R#, использующий System.String не останавливается.

A>Это потому что исходники пока маленькие

Боюсь, что у тебя коммерческие проекты меньше.

Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.

Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.

... << RSDN@Home 1.1.4 beta 2 >>

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

X>Только C# и парадигма GC позволяет использовать на пару соглашений меньше. И это хорошо! (ИМХО)

X>Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.

Ну это не так страшно, поскольку когда умрет дерево грохнется и эта ссылка. Хотя вашу специфику я понимаю.
Намного страшнее в этом плане делегаты. Вот тут можно попасть очень серъезно, поскольку это фактически публичный список и чисто психологически никто не задумывается что на ровном месте мы получаем накопление ссылок. Особенно неприятно когда событие статическое или принадлежит синглтону. В таком разе мы получаем самый натуральный лик.

... << RSDN@Home 1.1.4 beta 2 rev. 156>>

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

VD>Честно говря я даже не знаю как это возможно.
Как!? Я бы объяснил да это правилами запрещено...

... << RSDN@Home 1.1.4 rev. 142 >>

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

AVK>>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.

VD>Ну, решение все же не очень хорошее. Если бы не нацеленность на короткие захваты ресурсов, то они были бы бичем. Намного лучше было бы ввести класс типов — холдеры. А спасает именно то, что выбирается стратегия когда с ресурсом ведется работа в очень узком участке кода. Тут и юсинг работает неплохо. Но поять же это соглашение, а они не надежны. Всегда найдется орел который наплючет на на соглашения.

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

AVK>>Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.

VD>Помойму он имеет версию 8.0. Они не сбрасывали версии с шестой студии.

Неважно.

AVK>>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?

VD>Дык БД вообще пулится.

Это не отменяет необходимости закрывать соединения явно.

AVK>>А что, в природе бывают парсеры такого объема?

VD>Даже компиляторов не бывает. 50 мег на шарпе — это уже ОС.

Зато как звучит

... << RSDN@Home 1.1.4 beta 2 rev. 157>>

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

mdw>>А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)

mdw>>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релегиозную

SYG>А эти самые драйверы общаются между собой передавая друг другу полиморфные переменные или они все-таки как-то по старинке — не ОО? Что-то мне мерещится, что при написании драйверов Windows полиморфизмом не шибко пользуются...

Передают указатели на функции или структуры с указателями на функции. Т.е. кристально чистый полиморфизм ручной работы.

SYG>А эти самые драйверы общаются между собой передавая друг другу полиморфные переменные или они все-таки как-то по старинке — не ОО? Что-то мне мерещится, что при написании драйверов Windows полиморфизмом не шибко пользуются...

Когда мерещится самое время почитать доку.

... << RSDN@Home 1.1.0 stable >>

Hello, S.Yu.Gubanov!
You wrote on Thu, 19 Aug 2004 10:53:43 GMT:

SG> системах программирования) + безопасность (статический контроль типов
SG> переменных и автоматическое управление памятью) — наследование через
SG> границы модулей.

SG> Последняя строчка означает, что в КОП запрещено наследование от типов,
SG> реализованных в других модулях; наследовать можно только абстрактным,
SG> чисто интерфейсным типам.

Что-то фигня у вас какая-то получается. Наследование к типам, вообще-то, не
привязано. Делаю я, скажем, subclassing TreeView — это в чистом виде
наследование моего триконтрола от виндового. При этом какого он там типа в
comctl32.dll и класс ли это вообще (в С++ терминах), меня совершенно не
интересует. А интерфейс у него вообще сишный, а не плюсовый, так что
разговор об абстрактных, чисто интерфейсных типах переходит в несколько
другую плоскость.
С драйверами примерно такая же фигня.
Disclaimer: Я не утверждаю, что модель драйверов или окон в Windows является
или не является компонентной. Я утверждаю только, что аргументация у вас
хромает.

SG> Компонентно-ориентированное программирование возникло как своего рода
SG> дисциплина, т.е. набор определенных ограничений, налагаемых на механизм
SG> ООП, когда стало ясно, что бесконтрольное использование ООП приводит к
SG> проблемам с надежностью больших программных комплексов.

Лучший компонент — компилябельный исходник с документацией

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 beta

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.

SYG>Типичные но не все. Кроме того слово "компонент" очень широко в своем смысле. Да, конечно, в каком-то смысле этого слова данная система "компонентна". Но драйверы Windows не компонентны в смысле Компонентно ориентированного программирования (КОП).

Компонентны-по полной программе. Драйвер можно запустить без перезагрузки системы, а другая компонентность здесь не требуется. Все остальные требования тоже соблюдены кроме автоматического контроля памяти.

Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Спасибо!

Здравствуйте, S.Yu.Gubanov, Вы писали:

Ael>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ael>>Спасибо!

SYG>А противоположную по смыслу ссылку не желаете?

Давай. Кто-нибудь да пожелает. Я например....

Я — свихнувшееся сознание Джо.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

Ael>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ael>>Спасибо!

SYG>А противоположную по смыслу ссылку не желаете?

Я хочу услышать, то что мне надо

А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой, хотя конечно очень интересно. Но получить четко сформулированное обоснование подобных усилий было бы неплохо.

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

K>Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.

Точно так же как и от всех языков программирования. Была бы возможность писать программы с помощью мыши, отказались бы от кода вообще.

Вообщем, что-то ты рамки контекста не соблюдаешь

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

Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Да нет таких приемуществ. Ну, разве что рантайм в 20 мег на машину ставить не надо. А так все что можно сделать на С++ можно сделать и на дотнете (хтя бы на том же МС++). Ну, если только драйверы писать нельзя.

ЗЫ

В общем, очердной флэйм.

... << RSDN@Home 1.1.4 beta 2 >>

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

Ael>Я хочу услышать, то что мне надо

Ael>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой, хотя конечно очень интересно. Но получить четко сформулированное обоснование подобных усилий было бы неплохо.

1. C# формально сложнее С++. Им только пользоваться проще, так как продуман лучше.
2. На C# дотнет не заканчивается. Есть МС++. Есть MSIL. Тот С++ о котором ты говоришь — это не более чем подмножество МС++.

В общем, тебе просто хочется услышать то чтого на свете нет. Ну, или пофлэймить.

... << RSDN@Home 1.1.4 beta 2 >>

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

LVV>Лучше всего почитать первоисточник: Страуструп. Дизайн и эволюция С++. Там мэтр рассказывает, почему и как С++ получился таким — с самого начала и до появления STL. Очень интересное повествование.

Мэтру бы над языком порабоать, а не памфлеты писать. Глядишь и тем таких не возникло бы.

... << RSDN@Home 1.1.4 beta 2 >>

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

WH>Вот взять хотябы R# на сколько я знаю ты рание не имел дела с компиляторами но смог создать C# фронтенд соответствующий стандарту.

Ничего подобного там нет, там только парсер с зачатками ресолвинга имен. Единственная альтернативная реализация шарпа — моновская, содержит ошибки, в том числе и в парсинге.

... << RSDN@Home 1.1.4 beta 2 >>

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

SYG>>тот же Windows с Unix-ом не модульные и ничего вроде, нормально работают.
D>Вот только не надо валить в одну кучу современные Windows системы и технологию тридцатилетней давности.

О-о-о! Оценил. Уважаю.

По поводу COM-ов:
Я сказал что Windows не модульная система и еще сказал что под Windows нельзя писать модульные программы. Вы удивились и спросили, а как же тогда COM? Не беспокойтесь, все очень просто. Дело в том что среда Win32 и среда COM — разные вещи. Среда COM существует поверх среды Win32, точно также как среда BlackBox от Oberon Microsystems тоже существует поверх среды Win32.

Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET".

Цитата:
"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32"
Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз.

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

D>Не понял, откуда это следует.

На примерах чтоли объяснять?

Пусть есть три модуля:

MODULE M0;

TYPE
  T0* = POINTER TO ABSTRACT RECORD
    Value*: T1;
    Next* : T0;   
  END;

  T1* = POINTER TO ABSTRACT RECORD
    Value*: T0;
    Next* : T1;   
  END;

END M0.

MODULE M0T0;
IMPORT M0;

  PROCEDURE Create*(): M0.T0;

END M0T0.

MODULE M0T1;
IMPORT M0;

  PROCEDURE Create*(): M0.T1;

END M0T1.

Модули M0T0 и M0T1 создают объекты и отдают их каким угодно другим модулям, те отдают третьим, те четвертым и т.д. Кто должен заботится об уничтожении более не нужных объектов? Разумеется сборщик мусора, потому что счетчик ссылок в общем случае не сработает

VAR t0: M0.T0;
    t1: M0.T1;
BEGIN
  t0 := M0T0.Create();
  t1 := M0T1.Create();
  (* А теперь запутаем ссылки друг на друга: *)
  t0.Next  := t0; 
  t0.Value := t1;
  t1.Next  := t1;
  t1.Value := t0; 
  (* Сборщик мусора это запутывание вмиг распутает, а вот счетчики ссылок - будут отдыхать *)
END;

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

D>Вы бы тоже признались, что сморозили глупость и дело с концом.

Сделано:
http://www.rsdn.ru/Forum/Message.aspx?mid=739074&only=1

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

D>К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.

Правильно, зачем нам в программировании нужны циклические ссылки. Да нам даже и не циклические не нужны. Можно вообще без ссылок программировать...

SELECT object WHERE (name = 'MyObject') AND (year = 2004) AND ...

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

D>Такое сильное заявлений хорошо бы поддержать чем-то более серьезным (академичным, я б сказал

).

Вот тут:
http://cern.ch/oberon.day/talks/pfister.pdf
страница номер 13. Коротко и ясно.

Можно еще другие работы посмотреть:
http://cern.ch/oberon.day

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

Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.

Ael>Спасибо!

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

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

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

VD>Граматику С++ я хорошо изучил. Нет там ничего сложного. Вот в разрешении имен там каша. А граматика простая.
Re[4]: Граматика С++

VD>Ты кстати, подмогнеш нам на поприще языкостроения или уже передумал?
Блин еслиб 48 часов в сутках и спать не хотелось

Попробую найти время.

... << RSDN@Home 1.1.3 beta 1 >>

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

VD>>Ты кстати, подмогнеш нам на поприще языкостроения или уже передумал?
WH>Блин еслиб 48 часов в сутках и спать не хотелось

Та если бы спать не хотелось бы, то и 48 часов в сутках не нужно было бы

.

WH>Попробую найти время.

Было бы здорово! Молодые и толковые нам нужны!

... << RSDN@Home 1.1.4 beta 2 >>

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

K>Может их и можно проектировать, только зачем? Я еще не встречал ни одной системы имеющей сетевую (циклическую) архитектуру, которую вы тут проповедуете. Все что я видел, было древовидным (в крайнем случае), а обычно двух или трех уровневым. В такой архиетктуре проблеммы циклических ссылок просто нет. И такая архитектура вообщем всегда предпочтительнее сетевой. Чем проще тем лучше (проще не в смысле примитивнее).

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

K>Люди которые делали НЕТ и Яву — практики с огромным опытом и с огромным числом набитых шишек и со знанием подводных камней и течений, им до этих академических поделок просто нет никакого дела. Более того академические поделки как правило не выдерживают проверки на практике. Сразу обнажается куча непонятно откуда взявшихся проблем в дизайне, недостатков и т.д. и т.п.

Напрасно Вы так о них думаете.

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

SYG>>Кстати, под названием COM можно даже понимать ее последнюю версию COM3, которая носит гордое название ".NET".
D>Нельзя.

Вообще-то рабочее название дотнета как раз КОМ+. Могу ссылку МСДН-Маг дать...

SYG>>Цитата:
SYG>>"Среда CLR применяется в качестве первичного загрузчика кода вместо команды CoCreateInstance среды COM или команды LoadLibrary среды Win32"
SYG>>Основы платформы .NET, Том 1, Общеязыковая исполняющая среда, Д. Бокс, К Селлз.
D>Написали два чувака глупость. Теперь все будем повторять?

А в чем тут глупость? Абстрактно, но совершенно верно. Аналогия прямая.

D>Примеров не надо — я циклические зависимости разрываю силой воли.

D> К тому же надуманный пример с циклическими ссылками не опровергает тезиса о возможности программирования _без_ создания циклических ссылок.

Не. Не опровергает. Но мы вот в свое время в доволь потрахались рвыя училием воли циклические ссылки на АТЛ-ных синглтонах. Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.

... << RSDN@Home 1.1.4 beta 2 >>

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

Ну, кроме правил у КОМ был еще рантайм и разные фичи типа мидл-а и тлб.

Все вместе это называется технологией. В принципе базовые вещи можно делать и без КОМ-а или его аналогов. Но траху несоизмеримо больше.

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

Вот список фич С++ которые КОМ намеренно отключает, запрещает и подменяет своей реализацией:
1. Наличие не виртуального публичного интерфейса.
2. Множественное наследование.
3. Приведение типов.
4. Создание объектов.
5. Импорт типов.

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

... << RSDN@Home 1.1.4 beta 2 >>

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

D>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.

Каких?

... << RSDN@Home 1.1.4 beta 2 >>

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

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

D>>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.

AVK>Каких?

Хит, конечно, — порядок удаления зависимых объектов. Плюс недетерминированность времени удаления, как следствие — подвисание объектов и ресурсов. Такие вещи как Dispose Method от хорошей жизни не появляются.

А вот и пример: Re[10]: преимущества неуправляемого С++

... << RSDN@Home 1.1.3 stable >>

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

VD>Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.

И где там цикл?

... << RSDN@Home 1.1.4 beta 2 >>

D>А вот и пример: Re[10]: преимущества неуправляемого С++
Надо читать Re[9]: преимущества неуправляемого С++

... << RSDN@Home 1.1.3 stable >>

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

D>Хит, конечно, — порядок удаления зависимых объектов.

И что порядок? Объекты без финализатора могут удалятся в любом порядке, объекты с финализатором до вызова финализатора не удаляются. Где проблема, вызванная циклическими ссылками?

D> Плюс недетерминированность времени удаления,

При чем тут циклические ссылки?

D> как следствие — подвисание объектов и ресурсов.

Это следствие неумелого обращения с неуправляемыми ресурсами.

D>А вот и пример: Re[10]: преимущества неуправляемого С++

Пример чего?

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>>Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.

AVK>И где там цикл?

Что в упор не видишь? Один объект держит другой. Тот подписывается на событие и первый схватывает второй. Ну, а так как один из них синглтон, то на лицо полный аналог проблемы циклической ссылки. Так что цигл то том всегда. Просто проблемы прявляются только при некоторых обстоятельствах.

... << RSDN@Home 1.1.4 beta 2 >>

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

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

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

K>Ага, лев содержит ссылку на зайца, а заяц ссылку на почку волка. И все это чудно работает.

K>И где в этом примере циклические ссылки? и проблемма с ними?

родственные особи содержат днк с частично совпадающей информацией, некоторые днк — бракованные, особи носящие их имеют низкую жизнеспособность
эти особи с низкой жизнеспособностью первыми подчищаются GC в виде хищников, вирусов и стихийных бедствий

аналог ссылки — днк

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

D>Надо читать Re[9]: преимущества неуправляемого С++

Не было там никаких циклов, гонит он.

... << RSDN@Home 1.1.4 beta 2 >>

D>>Надо читать Re[9]: преимущества неуправляемого С++

AVK>Не было там никаких циклов, гонит он.

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

PS Мне действительно интресно это знать.

... << RSDN@Home 1.1.3 stable >>

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

AVK>>Не было там никаких циклов, гонит он.

D>Циклов, скорей всего нет, но проблема есть.

Ты еще помнишь первоначальный вопрос?

D>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.

Каких?

Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.

D> Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?

D>PS Мне действительно интресно это знать.

Именно так. А где здесь проблема? Если ты записываешь объект в контейнер то он не сдохнет пока не сдохнет контейнер. Делегат это тот же контейнер. В том примере проблема была из-за того что событие было у синглтона, а на него подписывались регулярно обновляемые сущности. И проблема там была не совсем с GC, а с неконтролируемым ростом числа подписчиков. С GC как раз проблему решить можно.

... << RSDN@Home 1.1.4 beta 2 >>

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

D>Циклов, скорей всего нет, но проблема есть. Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?

Прав. Но тут еще одна тонкость есть. Проблема появляется если тот самый источкник синглтон, т.е. никогда не умерает. Потому как в обычном случае умрут просто оба обхекта сразу.

D>PS Мне действительно интресно это знать.

Знай.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>>>Правда и в дотнете словить цикл можно. На событиях например. Забыл отписаться и приплыли тапочки к дивану.

AVK>>И где там цикл?

VD>Что в упор не видишь? Один объект держит другой. Тот подписывается на событие и первый схватывает второй.
VD> Ну, а так как один из них синглтон, то на лицо полный аналог проблемы циклической ссылки.

Там связь была только в одну сторону — от сингтона к форуму. Связи от форума к синглтону нет. Следовательно нет никакой циклической ссылки.

Если непонятно то вот примерная модель того что там происходит:

public class Test
{
    public event EventHandler SomeEvent;
    
    ...
    private ArrayList _items = new ArrayList();
    
    public void Refresh()
    {
        _items.Clear();
        foreach (Data d in SomeDataSource)
        {
            Item i = new Item();
            SomeEvent += new EventHandler(i.Handler);
        }
    }
}

public class Item
{
    public void Handler(object sender, EventArgs e)
    {
        ...
    }
}

И никаких циклических ссылок.

... << RSDN@Home 1.1.4 beta 2 >>

AVK>Ты еще помнишь первоначальный вопрос?
AVK>

D>>А циклические/перекрестные ссылки все-таки зло. И в системах c GC с ними можно огрести проблем.

AVK>Каких?

AVK>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.

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

Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.

D>> Если объект забыл отписаться от ивента, то он таки должен подвиснуть, пока источник событий не сдохнет. Или я не прав?

D>>PS Мне действительно интресно это знать.

AVK>Именно так. А где здесь проблема? Если ты записываешь объект в контейнер то он не сдохнет пока не сдохнет контейнер. Делегат это тот же контейнер. В том примере проблема была из-за того что событие было у синглтона, а на него подписывались регулярно обновляемые сущности. И проблема там была не совсем с GC, а с неконтролируемым ростом числа подписчиков. С GC как раз проблему решить можно.

А, я так и думал.

... << RSDN@Home 1.1.3 stable >>

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

AVK>Там связь была только в одну сторону — от сингтона к форуму. Связи от форума к синглтону нет. Следовательно нет никакой циклической ссылки.

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

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

Кстати, вики сами по себе средство борьбы с "проблемой которой нет".

AVK>Если непонятно то вот примерная модель того что там происходит:
Спасибо. Я эту багу сам делал.

... << RSDN@Home 1.1.4 beta 2 >>

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

D>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.

На практике с этим проблем нет. Да и с те ми же событиями один раз за два года вылезло. Сколько бы я такого на КОМ-е за тоже время словил бы?

... << RSDN@Home 1.1.4 beta 2 >>

D>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом. Но это больше теоретическая возможность, чем практическая.

VD>На практике с этим проблем нет. Да и с те ми же событиями один раз за два года вылезло.
У опытных практиков, конечно.

VD>Сколько бы я такого на КОМ-е за тоже время словил бы?
Надо было больше практиковаться.

... << RSDN@Home 1.1.3 stable >>

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

VD>Привет. Сингл-тон постоянно доступен через статическое свойство, так что считай что связь есть постоянно.

С кем? Со всеми сразу? Впрочем неважно, точно такую же проблему, только в меньших масштабах можно получить и без синглтона.

VD> Да и не в этом дело. Дело и менно в том, что грабли похожие. Просто встречаются намного реже. Забавно, что именно приколы с синглтонами нас допекали три года назда на КОМ-е. Тоже вроде бы все хокей, но про бессмертность синглтона забываешь.

Может это и грабли, но к циклическим ссылкам они никакого отношения не имеют.

VD>Кстати, вики сами по себе средство борьбы с "проблемой которой нет".

Вики это средство организации кеширования в условиях GC.

... << RSDN@Home 1.1.4 beta 2 >>

AVK>>>Итак, я по прежнему хочу услышать какие проблемы можно огрести в системах с GC от циклических/перекрестных ссылок.
D>>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
AVK>А при чем тут GC?
При том, что он подбирает объекты в неопределенном порядке.

D>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.
AVK>Нет такой проблемы. Все объекты с финализаторами не убираются сразу, а помещаются в finalization queue. После они отрабатывают (заметь, никто не убран) и лишь затем они уничтожаются, притом порядок уже абсолютно не важен.
Проблема не в доступе к удаляемому объекту, который действительно никуда не денется, а к его ресурсам, которые он мог освободить.

... << RSDN@Home 1.1.3 stable >>

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

D>>>Строго говоря, все проблемы с ссылками, в том числе перекрестными, возникают от неаккуратного проектирования/программирования.
AVK>>А при чем тут GC?
D>При том, что он подбирает объекты в неопределенном порядке.

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

D>>>Проблема перекрестных ссылок в том, что неопределен порядок удаления объектов. Если они захотят сделать что-то друг с другом перед смертью не факт, что это не окончится exception'ом.
AVK>>Нет такой проблемы. Все объекты с финализаторами не убираются сразу, а помещаются в finalization queue. После они отрабатывают (заметь, никто не убран) и лишь затем они уничтожаются, притом порядок уже абсолютно не важен.
D>Проблема не в доступе к удаляемому объекту, который действительно никуда не денется, а к его ресурсам, которые он мог освободить.

Кто мог осовбодить и при чем тут GC? Если есть неуправляемые ресурсы то GC их никак не освобождает, их нужно освобождать вручную.

... << RSDN@Home 1.1.4 beta 2 >>

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

D>У опытных практиков, конечно.

И не только.

VD>>Сколько бы я такого на КОМ-е за тоже время словил бы?
D>Надо было больше практиковаться.

Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

... << RSDN@Home 1.1.4 beta 2 >>

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

AVK>С кем? Со всеми сразу?

Со свеми живыми объектами.

AVK>Впрочем неважно, точно такую же проблему, только в меньших масштабах можно получить и без синглтона.

Дык она самоустранится рано или поздно. А с синглтоном она устойчивая...

VD>>Кстати, вики сами по себе средство борьбы с "проблемой которой нет".

AVK>Вики это средство организации кеширования в условиях GC.

А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.

... << RSDN@Home 1.1.4 beta 2 >>

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

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

D>>У опытных практиков, конечно.

VD>И не только.

VD>>>Сколько бы я такого на КОМ-е за тоже время словил бы?
D>>Надо было больше практиковаться.

VD>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

Прости, не смог удержаться.

... << RSDN@Home 1.1.3 stable >>

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

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

B>>мыслите более абстрактно
B>>аналогом модуля является не отдельная живая особь, а генетическая линия

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

B>>аналогия между воздействием естественного отбора на слабейших представителей видов животных (или же переработка бактериями трупов растений и животных и превращение их в ресурсы для новых поколений организмов) по моему очевидна
B>>а более сложную систему (включая сложность строения отдельных ораганизмов) чем экосистема, например тропического леса, по моему невозможно даже представить
B>>любая спроектированная человеком система уступает такой на миллионы порядков

K>И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

K>З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

а какое отношение имеет программирование к посроению архитектуры различных систем, модульности, сборке мусора=более точно — неиспользуемого материала?

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

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

K>>И причем здесь программирование, модули и сборка мусора? В природе вобщем-то нет никакой сборки мусора, т.к. мусора просто нет. Что считать мусором в природе? Если вы считаете труп мусором, то для бактерий, червей и т.п это лакомство. И почему бы тогда не считать мусором ваш собственный обед? А его употребление сборкой мусора и освобождение природы от бремени вареной картошки и т.п?

K>>З.Ы. ИМХО просто неуместно проводить аналогии в программирование с природой.

B>а какое отношение имеет программирование к посроению архитектуры различных систем, модульности, сборке мусора=более точно — неиспользуемого материала?

B>я не знаю как точно назвать данную дисциплину (пусть будет системная архитектура) , но она к программированию имеет такое же отношение как и ко всем другим профессиональным сферам человеческой деятельности и вообще к функционированию чего либо не представляющего собою единое целое (как например электрон, фотон и тп)

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

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

VD>А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.

Кто применяет?

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>>А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.

AVK>Кто применяет?

Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные. Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.

... << RSDN@Home 1.1.4 beta 2 >>

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

AVK>>Кто применяет?

VD>Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные.

Все это значит никто.

VD> Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.

Она исчезнет если выполнение события в фантомах не критично. А если критично то проблема остается. Вобще — вызов события у фантомов, даже если это временное явление это кривизна. Как минимум нужно вводить в подписчика признак фантомного состояния и не отрабатывать в этом состоянии событие, что в итоге ничуть не проще чем нормальная ручная отписка ненужных экземпляров от статического события.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>>Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные.

AVK>Все это значит никто.

Фигово у тебя с теримнами.

VD>> Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.

AVK>Она исчезнет если выполнение события в фантомах не критично.

Да события тут могут быть даже не причем. Это общее решение. К тому же никаких фантомов тут нет. До сборки мусора объект есть и доступен по вику, после ссылки уже пусты.

AVK> А если критично то проблема остается. Вобще — вызов события у фантомов, даже если это временное явление это кривизна. Как минимум нужно вводить в подписчика признак фантомного состояния и не отрабатывать в этом состоянии событие, что в итоге ничуть не проще чем нормальная ручная отписка ненужных экземпляров от статического события.

Да лишнее все это. Мне кажется ты начинаешь выдумывать проблему.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>Да события тут могут быть даже не причем. Это общее решение. К тому же никаких фантомов тут нет. До сборки мусора объект есть и доступен по вику, после ссылки уже пусты.

Он может и доступен, но уже никому не нужен и отрабатывать событие не должен, а он будет отрабатывать пока не запустится GC. Вобщем в данной конкретном случае слабые ссылки половинчатое решение.

... << RSDN@Home 1.1.4 beta 2 >>

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

AVK>Он может и доступен, но уже никому не нужен и отрабатывать событие не должен, а он будет отрабатывать пока не запустится GC. Вобщем в данной конкретном случае слабые ссылки половинчатое решение.

Ну, должен не должен — это все завист от задачи. Во многих случаях проблем не будет. Хотя несомненно можно создать ситуацию когда это будет приводить к проблемам.

... << RSDN@Home 1.1.4 beta 2 >>

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

K>Думаю пока рано делать выводы. Все "тяжелые" программы (САПРЫ, оффисы и т.п.) которые мы юзаем пока в unmanaged коде.

И глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю, глюкаю...

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>>>Сколько бы я такого на КОМ-е за тоже время словил бы?
D>>Надо было больше практиковаться.

VD>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

ха! это ну совсем ни о чем не говорит. "Бумажный тигр" называется

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

VD>>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...

W>ха! это ну совсем ни о чем не говорит. "Бумажный тигр" называется

Это называется трепач находка для шпионов. Попробуй сделайть хоть десяту долю того...

... << RSDN@Home 1.1.4 beta 2 >>

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

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

Кто сказал? Ничего подобного. Программа должна управлять жизненным циклом объекта только в том случае если он нам интересен.

R>GC во первых — просто развращает,

Ты пробовал что так говоришь?

R> во вторых делает вообще невозможным поиск Memory leak-ов путем автоматическог анализа кода и очень сильно затрудняет их поиск путем Code Review.

. Мне понравилось — главный недостаток GC это мемори лики. Вобщем на самом деле для того чтобы сделать лик надо постараться. А уж если умудрился то никакой автоматический анализ кода тебя уже не спасет, поскорльку лики в условияхъ GC по формальным признакам ничем не отличимы от нормального кода и лики там на чисто логическом уровне.

AVK>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

R>Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC

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

R> (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).

finalize это уже для того чтобы аварии не вышло и применяют его довольно редко. Когда же хотят сделать освобождене неуправляемых ресурсов автоматическим используют отнюдь не finalize.

R>Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.

Практика показывает что это не так.

R>Более того, не всегда есть возможность знать заранее в каком случае "Память больше не ресурс", а когда обьект/некоторые его части были созданы на внешнем сервере,

Тогда это неуправляемый ресурс.

R>Даже когда разработчик исползует jdbc, он вполне может не знать, будет ли незакрытый RecordSet просто Memory leak-ом на 20kb в java машите, который исправит GC, или незакрытым курсором в БД, который "весит" десятки мегабайт.

Это тоже неуправляемый ресурс. И если разработчик не знает что коннекшен к базе неуправляемый то ему уже ничто не поможет.

R>>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
AVK>>А вот парсер R#, использующий System.String не останавливается.

R>Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.

Так получается что проблема не в GC, а в конкретной реализации?

AVK>>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.

R>Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью",

GC просто выполняет больше работы.

R> но когда такая возможность предоставляется самой технологией,

Интересно, это как? Возможность либо есть, либо ее нету.

R>и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.

Никаких иллюзий не создается. Памятью управлять не надо на самом деле, неуправляемыми ресурсами управлять необходимо. Где здесь ты иллюзию увидел?

R>Например в Java я предпочел бы возможность решать в каждом отдельном случае делать "delete a" или "System.manageLifeTime(a)".

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

R>Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать,

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

R> а в обратных случаях часто возникают большие проблеммы.

Классно у тебя получается — технологию А осваивать быстро и просто, технологию Б сложно. Отсюда вывод — технология А отстой.

... << RSDN@Home 1.1.4 beta 2 >>

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

R>Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).
R>Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.

В полноценных современных ОО ОСях с интегрированным сборщиком мусора проблем с неуправляемостью нет. Проблемы возникают только когда Вы пытаетесь на языке со сборщиком мусора работать поверх древней неуправляемой ОСи: http://www.rsdn.ru/Forum/Message.aspx?mid=745571&only=1

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

ГВ>Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.

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

Лично я, например, был шокирован, когда осознал, что, скажем, в системах с GC широко применяется функция возвращающая список динамически созданных ею же самой объектов:

Obj = POINTER TO RECORD
    Next: Obj;
    (* ... *) 
  END;

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

Или вот другой пример, собственно, Вы Геннадий сами же написали критическое сообщение по поводу "Абстрактного Агрегата":
http://www.rsdn.ru/Forum/Message.aspx?mid=744961&only=1
демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".

Здравствуйте, S.Yu.Gubanov, Вы писали:

ГВ>>Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.

SYG>Боюсь что это не так, а наоборот. Проектирование для системы имеющей сборщик мусора отличается от проектирования для системы ее не имеющей. Программист, как минимум, испытывает шок при переходе к системам с GC.

Да, испытывает.

SYG>Надо очищать-освобождать свой разум от старых стереотипов ручного контроля памяти.

Сдаётся мне, что не всё так просто. ИМХО, нужно освобождать свой разум от заблуждений, что что-то может быть в компьютере "бесплатно". А ещё от того, что компьютер представляет собой систему с бесконечной памятью и бесконечными дисками. Это называется самообманом.

SYG>Лично я, например, был шокирован, когда осознал, что, скажем, в системах с GC широко применяется функция возвращающая список динамически созданных ею же самой объектов:
SYG>

SYG>Obj = POINTER TO RECORD
SYG>    Next: Obj;
SYG>    (* ... *) 
SYG>  END;
SYG>

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

Что-то я не совсем понимаю.

А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?

SYG>Или вот другой пример, собственно, Вы Геннадий сами же написали критическое сообщение по поводу "Абстрактного Агрегата":
SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=744961&only=1
SYG>демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".

Там приведена довольно подробная аргументация по этом поводу. И сказано, кстати, что к GC она не имеет никакого отношения.

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

K>ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.

Гы. Именно так (насколько я знаю) и поступаю все разработчики свербольших микросхем вроде транзисторов. Они делять яего на виртуальные компоненты с четким интерфейсом и уже на базе этих компонентов делают более большие блоки.

В общем, компонет не обязан быть боьшим. А вот интерфейс действительно лучше иметь обозримых размеров.

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

... << RSDN@Home 1.1.4 beta 2 >>

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

SYG>>Каковы размеры Ваших монолитных систем?
K>Около миллиона строк.

Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?

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

SYG>>Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?

K>Это как же их учтешь? после развертки? нет обычный код. включая фортрановский.
K>Компилируется если с нуля минуты три. В релизе поболее.

Как учесть-то? Ну, это просто, типа как Borland C++ Builder 6.0 когда компилирует, то в окошке показывает сколько строчек кода он уже скомпилировал. Причем показывает именно реальное количество, то есть то которое получается после разворачивания шаблонов. Смотришь и глаза из орбит вылазиют — в проге которуя я однажды сопровождал было 19 миллионов строчек, хотя вручную написанных в тысячу раз поменьше было, остальное = Борландовская VCL + шаблоны всякие.

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

K>Скорее всего мы по разному понимаем слово монолитная. Монолитная для меня это когда интерфейс не отделен от реализации. Т.е. обычная библиотека классов которая линкуется статически, компонентность предполагает одтеление интерфейса от реализации, т.е. под одним интерфейсом может скрыватся несколько реализаций. Как следствие этого компонентнвй обьект может быть создан только динамически т.к. используемая реализация не известна компилеру-компоновщику, и юзатся он может только через интерфейс. Такой подход во многих случаях просто не нужен. Т.е. можно иметь несколько хорошо спроектированных библиотек классов (которые потихоньку эволющионируют) и на их базе создется программа. Т.к. все линкуется статически получается монолитная архитектура (один экзешник, куда уж монолитнее)

Ну Вы монстр! В миллионострочной программе не пользоваться разделением интерфейса от реализации я бы свихнулся. Я свою последнюю прогу вот так писал:
http://www.rsdn.ru/Forum/Message.aspx?mid=747348&only=1

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

SYG>Ну Вы монстр! В миллионострочной программе не пользоваться разделением интерфейса от реализации я бы свихнулся. Я свою последнюю прогу вот так писал:
SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=747348&only=1

мне это не подходит, т.к. геометрические стуктуры очень ветвистые.
а то что происходит в интефейсе так это очень малая часть работы по сравнению со всем остальным.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>Как учесть-то? Ну, это просто, типа как Borland C++ Builder 6.0 когда компилирует, то в окошке показывает сколько строчек кода он уже скомпилировал. Причем показывает именно реальное количество, то есть то которое получается после разворачивания шаблонов. Смотришь и глаза из орбит вылазиют — в проге которуя я однажды сопровождал было 19 миллионов строчек, хотя вручную написанных в тысячу раз поменьше было, остальное = Борландовская VCL + шаблоны всякие.
Разварачиваются не шаблоны, а макросы. Шаблоны работают на уровне АСТ, а не текста.

ЗЫ багланд дебилдер это не компилятор, а недразумение.

... << RSDN@Home 1.1.3 beta 1 >>

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

WH>Разварачиваются не шаблоны, а макросы. Шаблоны работают на уровне АСТ, а не текста.

А includ-ы текстовых файлов работают на каком уровне?

Какая разница на каком уровне что работает. Общее реально полученное после всех подстановок макросов, шаблонов, инклюдов количество строчек составляет десятки миллионов. Пусть Вы их собственными глазами и не видите, но они все равно подразумеваются.

Здравствуйте, S.Yu.Gubanov, Вы писали:

SYG>А includ-ы текстовых файлов работают на каком уровне?
Это макросы.
SYG>Какая разница на каком уровне что работает.
Большая. Шаблон!=макрос. Шаблоны не генерируют текст. Они не порождают дополнительные строки. Этим занимается препроцессор. А шаблонами ворочает компилятор.
SYG>Общее реально полученное после всех подстановок
SYG>макросов,
Раскрытие макроса колличество строк не увеличивает. Макрос раскрывается в одну строку. Да длинною но одну.
Вот работа макроса

template<class Arg, class B> inline const lambda_functor< lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<lambda_functor<Arg>, typename reference_argument <const B>::type> > > operator%= (const lambda_functor<Arg>& a, const B& b) { return lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<lambda_functor<Arg>, typename reference_argument <const B>::type> > (tuple<lambda_functor<Arg>, typename reference_argument <const B>::type>(a, b)); } template<class A, class Arg> inline const lambda_functor< lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<typename reference_argument <A>::type, lambda_functor<Arg> > > > operator%= (A& a, const lambda_functor<Arg>& b) { return lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<typename reference_argument <A>::type, lambda_functor<Arg> > > (tuple<typename reference_argument <A>::type, lambda_functor<Arg> >(a, b)); } template<class ArgA, class ArgB> inline const lambda_functor< lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<lambda_functor<ArgA>, lambda_functor<ArgB> > > > operator%= (const lambda_functor<ArgA>& a, const lambda_functor<ArgB>& b) { return lambda_functor_base< arithmetic_assignment_action<remainder_action>, tuple<lambda_functor<ArgA>, lambda_functor<ArgB> > > (tuple<lambda_functor<ArgA>, lambda_functor<ArgB> >(a, b)); }

SYG>шаблонов,
Шаблоны работают на уровне АСТ текст не производят вобще.
SYG>инклюдов
Вот они и плодят строки в каждой единице трансляции
SYG>количество строчек составляет десятки миллионов.
При грамотной организации проекта получить больше полумиллиона строк в одной единице трансляции (единица трансляции это один *.cpp файл и все что в него проинклудили) довольно трудно. Причем подавляющие колличество кода будет вынесено в так назаваемые прекомпилированные заголовки(PCH). Те реально при компиляции одной единици трансляции обрабатывается несколько тысячь строк. А те пол миллиона строк лежат в прекомпилированном виде.
Не смотря на то что багланды вродебы поддерживают PCH де-факто они "работают" весьма хреново.
SYG>Пусть Вы их собственными глазами и не видите, но они все равно подразумеваются.
Ну почемуже не вижу? Если захочу то могу и увидить. И даже иногда смотрю когда макросы отлаживаю.

... << RSDN@Home 1.1.3 beta 1 >>

, но просто наткнулся
http://www.codeproject.com/managedcpp/quake2.asp

Performance
Getting existing projects into managed code is useful since it offers a lot of design freedom, for example:

Use garbage collection or manage memory yourself.
Use .NET Framework methods or Window API calls directly.
Use .NET Framework classes or existing libraries (STL for example).
However, usefulness only matters if the managed application has the performance you require. Running Quake II.NET in the timedemo test indicates the managed version performs about 85% as fast as the native version. The performance of the managed version was acceptable and testers did not notice a difference between the two versions.

Выводов намеренно не делаю, так как вполне допускаю, что квака неоптимально
написана с точки зрения managed-C++

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

K>Это как же их учтешь? после развертки? нет обычный код. включая фортрановский.
K>Компилируется если с нуля минуты три. В релизе поболее.

3 минуты более миллиона строк С++-кода! Изумительно! (с)

... << RSDN@Home 1.1.4 beta 2 >>

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

WH>Разварачиваются не шаблоны, а макросы. Шаблоны работают на уровне АСТ, а не текста.

Ну, компилятор то может все что хочешь учесть.

WH>ЗЫ багланд дебилдер это не компилятор, а недразумение.

Есть момент. Но даже он миллион сток за три минуты перемолотить не в силах.

... << RSDN@Home 1.1.4 beta 2 >>

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

D>Да, если система не желает полагаться на выполнение правил разработчиками компонентов, единственным средством контролировать время жизни объектов остается общесистемный GC.

Разработка любой системы так или иначе завязана на выполнение разработчиками каких-то правил.
Писать с отступами например. Ну подумаешь правилом больше, правилом меньше. Зри в корень!
Либо на Х языке что-то можно написать, либо нельзя. И только это поределяет язык Х, а удобсвто это на самом деле весьма субъективыный фактор.

По-моему, причина таких настроений заключается в том, что GC в таких языках, как Java и C#, является чужеродной сущностью, внесенной в семантику Си++, чужеродной даже по синтаксису. Действительно, если создание объекта выглядит как

Object a = new Object;

то естественно задать вопрос: а когда этот объект будет удален?

Однако если посмотреть на другие языки, с давней традицией GC, прежде всего функциональные (Lisp, ML, Erlang) и, возможно, Smalltalk, то там этого вопроса просто не возникает. Там действительно память — не ресурс, а "объекты" — не вещи, которые нужно создавать и разрушать. GC применяется только к значениям, а не к "объектам", и упрекать их за то, что в них не проводится явное освобождение памяти — все равно что упрекать Си++, что в нем не проводится явное освобождение, например, литерала "Hello, world\n", когда он становится больше не нужным во всем известной программе.

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

AVK>>>А вот парсер R#, использующий System.String не останавливается.

A>>Это потому что исходники пока маленькие

AVK>А тебе сколько надо? И для какого языка парсер значительно сложнее?

Кстати, да. Именно сложность парсера у Шарпа выше чем у большинства языков (если не у всех) в следствии тучи мелких фич типа событий, делегатов... С++ точно объем парсера имет меньший.

А при работе с семантикой строки уже не создаются, так что там разницы никакой.

В общем, по факту парсинг на Шарпе идет очень даже шустро, а все рассказы о тормозах работы со строками выдумка.

... << RSDN@Home 1.1.4 beta 2 >>

VD>Боюсь, что у тебя коммерческие проекты меньше.

Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.

Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).

VD>Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.

БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.
Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.

Удач.

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

VD>Причем обычно народ ловит лики именно памяти.

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

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

A>>Это потому что исходники пока маленькие

VD>Боюсь, что у тебя коммерческие проекты меньше.

Объем исходников где-то 3 мега. Причем это Шарп. А он в 1.5-2 раза компактрее.

Всего 3? У меня папка My Projects\Done (то что сделано и забыто) 13 МБ, а я папочки Release/Debug и всё другое лишнее оттуда потёр. А ещё текущие проекты...

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

LM>Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).

Твоих или воообще?

LM>БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.
LM>Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.

+1

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

LM>БРЕД СИВОЙ КОБЫЛЫ, извините. Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.
LM>Проектировать и разрабатывать просто надо уметь. Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.

Это так.

Только C# и парадигма GC позволяет использовать на пару соглашений меньше. И это хорошо! (ИМХО)

Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.

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

A>>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет

Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
AVK>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.

То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.

A>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.
AVK>Ужас? Ты изучал код дотнета? Каким образом?

IT Изучал.Во всяком случае он так утверждает.

AVK>>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
A>>Однако на практике их путать приходится

AVK>Расскажи о своей практике.

Файлы открывать надо? Всё, этого достаточно.

A>>Это потому что исходники пока маленькие

AVK>А тебе сколько надо?

Мегабайт 50.

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

A>>>Это потому что исходники пока маленькие

AVK>>А тебе сколько надо?
A>Мегабайт 50.
Тут не в объеме исходников дело и не в ГЦ, а в том как со строками обращаются. Дык вот если строки плодит только лексер, а парсер их только использует и не создает новых то тормозов не будет.

... << RSDN@Home 1.1.4 rev. 142 >>

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

AVK>>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.

A>То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.

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

A>>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.
AVK>>Ужас? Ты изучал код дотнета? Каким образом?

A>IT Изучал.Во всяком случае он так утверждает.

Понятно. Так бы и сказал что говоришь с чужих слов. А что и как IT на эту тему писал я знаю, мы в свое время этот вопрос с ним обсуждали. Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является. Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.

AVK>>>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
A>>>Однако на практике их путать приходится

AVK>>Расскажи о своей практике.

A>Файлы открывать надо? Всё, этого достаточно.

Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?

A>>>Это потому что исходники пока маленькие

AVK>>А тебе сколько надо?

A>Мегабайт 50.

А что, в природе бывают парсеры такого объема?

... << RSDN@Home 1.1.4 beta 2 rev. 156>>

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

WH>Тут не в объеме исходников дело и не в ГЦ, а в том как со строками обращаются. Дык вот если строки плодит только лексер, а парсер их только использует и не создает новых то тормозов не будет.

А зачем их плодить?

... << RSDN@Home 1.1.4 beta 2 rev. 156>>

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

AVK>А зачем их плодить?
Если ты про лексер то у него работа такая... исходник на лексемы нашинковать чтобы парсер работал на болие высоком уровне абстракции...
А если про парсер то и я думаю незачем... Хотя не извесно кто тот парсер на жабе писал который в даун уходит... Я однажды компилятор видел

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

... << RSDN@Home 1.1.4 rev. 142 >>

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

AVK>Имеет. Однако IT свою статью писал когда только экспериментировал с дотнетом и еще свежи были плюсовые воспоминания. Спроси у него сейчас, вполне возможно что он относится к данному недостатку GC уже не так критически.

Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.

AVK>Понятно. Так бы и сказал что говоришь с чужих слов.

А я и сказал

AVK>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.

А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт. Или несёт? Ведь в Си++ пишут

for (int i = 0; i < 3; ++i)
 {
  somestream mystream;
  mystream << "text"
 }

А в C# нужен using иначе на второй итерации можно получить облом.

AVK>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?

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

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

LM>Хи-хи.... Проект на С++ исходники метров эдак 20 — 30 ( точно трудно оценить — много подсистем ).

У тебя случаем не разделение личности? Я говорил о адонзе и его проектах.

К тому же я не утвреждал, что РШарп самый большой проект. Я просто сказал, что он очень не мальенький проект.

VD>>Что касается ЖЦ, то вся твоя теория рассылпается при упоминании простого факта. В реальных приложений написанных на Шарпе проблем с контролем ресурсов возникает очень мало. А в С++ хватает. Причем обычно народ ловит лики именно памяти.

LM>БРЕД СИВОЙ КОБЫЛЫ, извините.

Не хочется извинять.

LM> Никаких проблем с ремурсами, а ТЕМ БОЛЕЕ ликов памяти НЕТ.

Рад за тебя. И конечно никогда не было. Пишите без ошибок...

LM>Проектировать и разрабатывать просто надо уметь.

Это совет? Или констатация собственной крутости?

LM> Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.

А еще и без исключений. Ню-ню. Очень правильно. Поделись что пишешь то?

LM>Удач.

Тебе она нужнее.

... << RSDN@Home 1.1.4 beta 2 >>

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

X>Кстати, в C# получить утечку памяти — легче легкого. Достаточно забыть присвоить в null указатель (например на один узелок в развесистом дереве), чтобы память несколлектилась.

Это не лик. Лик это недоступные ресурсы которые рельзя освободить. Лик можно сделать забыв отписавшись от события на синглонах.

... << RSDN@Home 1.1.4 beta 2 >>

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

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

VD>>Причем обычно народ ловит лики именно памяти.

A>Это от бескультурия.

Точно. И у тебя оново коенечно небыло. Ладно. До добра это не доведет. Завязываем.

A> Удачно подобрав умный указатель словить утечку памяти довольно сложно.

А не удачно?

A>У меня конечно тоже бывают утечки, но они всегда только от ручной работы с выделением и освобождением ресурсов.

А у всех так. Вон только ЛиСаус (так и тяне сказать Брюс

) имеет 20-30 (гы сам разбор смешен) и не имеет ни единой утечки. Причем никогда их не ловил.

A>Посему я прежде чем пользоваться ресурсом пишу класс.

Раньше я далал так же. Вот только ошибки...

Да и код пишут разные люди. Ну, и не всегда обертки помогают. Есть и связь с системой, и другие фени. А я тепер очертки писать не надо. Просто пишешь прикладной код и все.

В общем, рассказ о трудности управления ресурсами в дотнете — это домыслы тех кто серьезно с ним не работал.

Любая обертка — это труд и правило которое нужно соблюдать.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>Всего 3? У меня папка My Projects\Done (то что сделано и забыто) 13 МБ, а я папочки Release/Debug и всё другое лишнее оттуда потёр. А ещё текущие проекты...

А ты еще потри все библиотечки, генерируемые файлы и т.п. А посчитай только рабчие файлы.

Хотя к делу это не относится. Думаю никто не осмелится назвать полноценный парсер в три метра исходников "малым количеством кода". Его боле чем достаточно для определения быстродействия... по крайней мере при работе со строками и большим количеством объектов. Так что забывай все эти догмы.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.

Цитату, плиз, где он написал о сложности работы с ресурсами в дотнете.

Ну, и он тут не далеко. Можно спросить его мнение лично.
A>IT Изучал.Во всяком случае он так утверждает.

AVK>>Расскажи о своей практике.

A>Файлы открывать надо? Всё, этого достаточно.

Цитату, плиз.

A>Мегабайт 50.

Да? И у тебя такая система есть?

Весь компилятор С++ занимает на порядок меньше кода.

... << RSDN@Home 1.1.4 beta 2 >>

Здравствуйте, S.Yu.Gubanov,

почикано излишнее цитирование — Odi$$ey

А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)

Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релегиозную

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

почикано излишнее цитирование — Odi$$ey

mdw>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релИгиозную

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

A>>Это от бескультурия.
VD>Точно. И у тебя оново коенечно небыло.

Было. Ноя быстро переучился.

A>> Удачно подобрав умный указатель словить утечку памяти довольно сложно.
VD>А не удачно?

А их по сути всего триа auto_ptr, shared_ptr и com_ptr. перепутать их довольно сложно

VD>А у всех так. Вон только ЛиСаус (так и тяне сказать Брюс

) имеет 20-30 (гы сам разбор смешен) и не имеет ни единой утечки. Причем никогда их не ловил.

Я вообще не понял что ты хотел сказать

D>Любая обертка — это труд и правило которое нужно соблюдать.

using тоже правило.

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

VD>А ты еще потри все библиотечки, генерируемые файлы и т.п. А посчитай только рабчие файлы.

Влад, я не дурак.

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

A>>То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.
VD>Цитату, плиз, где он написал о сложности работы с ресурсами в дотнете.

Я говорю не о сложности (где ты это углядел?) а о необходимости заплатки using.

A>>Файлы открывать надо? Всё, этого достаточно.
VD>Цитату, плиз.

Цитату на что? На то что в серьёзной программе естьработа с файлами?

VD>Да? И у тебя такая система есть?
VD>Весь компилятор С++ занимает на порядок меньше кода.

Настоящие ирокезы работают без IDE?

... << RSDN@Home 1.1.4 beta 2 >>

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

WH>А если про парсер то и я думаю незачем... Хотя не извесно кто тот парсер на жабе писал который в даун уходит...

Ну, так выводы то какие? Все же дело в руках? Я Яву знаю не шибко. Но и этого достаточно, чтобы утверждать, что значительно моедленее парсер не стал бы будь он переписан на ней.

WH>Я однажды компилятор видел

Честно говря я даже не знаю как это возможно. Древние компиляторы делали несколько прохдов (чтений исходников). Далалось это из-за нехвтки памяти. Это сйчас можно мегабайтный исходник заглотить и не чавкнуть. А тогда... Вот они тормозили копитально. Но как можно по строчке компилировать? Это только для разных командных интепретаторов возможно.

... << RSDN@Home 1.1.4 beta 2 >>

AVK>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.

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

AVK>Тому свидетельство появление юзинга в VB.NET в 2.0 в практически таком же виде.

Помойму он имеет версию 8.0. Они не сбрасывали версии с шестой студии.

AVK>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?

Дык БД вообще пулится. Так что запросил — отпустил. Все в юсингах и терть нечего. Друое дело, что можно было бы и без них.

AVK>А что, в природе бывают парсеры такого объема?

Даже компиляторов не бывает. 50 мег на шарпе — это уже ОС.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.

Не. Вопрос в том напрягает он или нет. Так вот не напрягает. Он тебе и говорит — чистая теория не подтверждающаяся на практике.

A>А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт.

Эта конструкция вообще к ЖЦ отношение не имеет. Она как раз позволяет автоматически контролировать все что вгодно кроме памяти.

A>Или несёт? Ведь в Си++ пишут
A>

A>for (int i = 0; i < 3; ++i)
A> {
A>  somestream mystream;
A>  mystream << "text"
A> }
A>

A>А в C# нужен using иначе на второй итерации можно получить облом.

Когда мне нужо было писать много файлов (сотни) я сделал два вот таких хэлпера:

public static string ReadFile(string fileName)
{
    using (StreamReader reader = new StreamReader(
                     fileName, Encoding.Unicode))
    {
        return reader.ReadToEnd();
    }
}

public static void WriteFile(string fileName, string code)
{
    using (StreamWriter writer = new StreamWriter(
                                                 fileName, false, Encoding.Unicode, code.Length))
                {
        writer.Write(code);
    }
}

И далее чтение файлов вглядит как атомарная операция при которой не мыслимо не закрыть что-то:

...
if (!File.Exists(fileName) || code != ReadFile(fileName))
{
    WriteFile(fileName, code);
    return true;
}

Благадаря особенностям ЖЦ такой подход еще и поднимает скорость.

С 90% ресурсов можно ралотать так же. Ну, а с 10 прийдется поработать по плотнее. Но все равно сложностей особых нет.

Не за гормаи Лонгхорн с его выньФС. В нем вместо файлов будут объекты (дотнытные) и контролировать файлы как таковый зачастую просто не прийдется. С БД и ГДИ проблем нет уже сейчас. Так что все ОК, и ты просто не проникся.

A>Я говорил о возможности ошибки, а не о наличии.

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

Я как м ты избегал исключений, делал обертки и т.п. Но вкусив Шарпа я понял, что 80% времени тратил на борьбу с ветренными мельницами.

A> Твой богатый опыт и знания могут даже незаметно для тебя, на интуитивном уровне, помогать избегать ошибок.

Так и есть. Есть куча ламеров которые просто не пользутся юсингами. Но поймать незакрытый файл очень просто. А вот проход по памяти или лик памяти порой очень сложно.

К сожалению приколы есть и в шарпе. Вот недавно в Янусе отловили багу которую повесил я. Дело втом, что я не отключался от событий при чтении данных (каждый раз подписываясь на них). В итоге количество обработчиков росло со временем и в конце концов приводило к тормозам (в 1.1. делегаты тормозят при больших количествах подключенных вызовов). Но эта была единственная серьезная оишибка связанная с забычивостью. На С++ таки трясся над подобными моментами.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>Ну, решение все же не очень хорошее. Если бы не нацеленность на короткие захваты ресурсов, то они были бы бичем. Намного лучше было бы ввести класс типов — холдеры. А спасает именно то, что выбирается стратегия когда с ресурсом ведется работа в очень узком участке кода. Тут и юсинг работает неплохо. Но опять же это соглашение, а они не надежны. Всегда найдется орел который наплючет на на соглашения.

Вот-вот! вот об этом я и хочу сказать!

Влад, я опять с тобой согласен! Может я болею чем-то?

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

A>Я говорю не о сложности (где ты это углядел?) а о необходимости заплатки using.

Вот история:

A>>Человек которые не привык вовремя освобождать память с лёгкость забудет закрыть файл... и привет Никакой GC не спасёт от идиотского "The process cannot access the file "test.txt" because it is being used by another process." на пустом месте.
AVK>Рома, теоретизирования хорошо когда нет практики. А вот когда она есть, она показывает — таких проблем не возникает.

То есть статья IT Сжизнью ничего общего не имеет. Так и запишем.

A>Цитату на что? На то что в серьёзной программе естьработа с файлами?

Например, этого:

A>>using не от хорошей жизни появился. Вспомни первый Framework. Там код практически без using был написан за счёт try/finally. Выходил какой-то ужас.

VD>>Да? И у тебя такая система есть?
VD>>Весь компилятор С++ занимает на порядок меньше кода.

A>Настоящие ирокезы работают без IDE?

А IDE интегрирована в компилятор? Да и в студии тоже 50 метров вряд ли наберется.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>using тоже правило.

Да. Но их на порядок меньше. Хотя о чем это я? На два-три порядка.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>Вот-вот! вот об этом я и хочу сказать!

A>Влад, я опять с тобой согласен! Может я болею чем-то?

Поверь про простоту программирования я тебе тоже не вру.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>Да. Но их на порядок меньше. Хотя о чем это я? На два-три порядка.

Влад, если в C# 2 правила, то 3 порядка больше означает, что в Си++ 2000 правил. Ты не переборщил, не увлёкся?

ИМХО правил 25 от силы наберётся.

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

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

mdw>>>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релИгиозную

VD>То есть тебе показалось мало оверквотинга в первом посте и ты решил увеличить его вдвое?

Виноват.
В любом случае, спасибо за релевантный и вежливый коментарий.
А что движок позволяет редактировать собственные сообщения?

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

AVK>>Имеет. Однако IT свою статью писал когда только экспериментировал с дотнетом и еще свежи были плюсовые воспоминания. Спроси у него сейчас, вполне возможно что он относится к данному недостатку GC уже не так критически.

A>Вопрос не в том как относится к чему-то IT, вопрос в тмо есть недостаток (пусть и не большой) или нету.

Недостатки есть у всего. Но по твоим словам этот недостаток нивелирует преимущества GC, а это совсем не так.

AVK>>Да, действительно, using поздняя конструкция, однако ее достоинств это никак не умаляет и заплаткой она не является.

A>А что это? Это очень хорошая заплатка, но именно заплатка. Эта конструкция создана под внутреннее устройство GC и никакой логики не несёт. Или несёт?

При чем тут несет/не несет? Это просто сокращенная запись try..finally..Dispose(). Чтобы писать меньше. Обычно такие вещи называют syntactic sugar, а не заплатка.

AVK>>Что достаточно? Я вот проектик сейчас пишу, там уже наверное мег 15 кода, если не больше. Там и файлов дофига, а еще больше работы с БД, ресурсы которой тоже неуправляемые. И вот странно — что то я проблем с незакрытым файлом или соединением с БД не припомню. Совсем. Ни одного случая. Так что ты там говорил о практике?

A>Я говорил о возможности ошибки, а не о наличии.

Нет уж, вот твои слова:

AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.

A>Однако на практике их путать приходится

Так что ты говорил о наличии

A> Твой богатый опыт и знания могут даже незаметно для тебя, на интуитивном уровне, помогать избегать ошибок.

Этот проект делаю не один я, а команда программистов разной квалификации. Проблем нет ни у кого.

... << RSDN@Home 1.1.4 beta 2 rev. 157>>

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

VD>>Да. Но их на порядок меньше. Хотя о чем это я? На два-три порядка.

A>Влад, если в C# 2 правила, то 3 порядка больше означает, что в Си++ 2000 правил. Ты не переборщил, не увлёкся?

ИМХО правил 25 от силы наберётся.

Он не про правила, а про количество их применений в коде.

... << RSDN@Home 1.1.4 beta 2 rev. 157>>

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

A>>Влад, если в C# 2 правила, то 3 порядка больше означает, что в Си++ 2000 правил. Ты не переборщил, не увлёкся?

ИМХО правил 25 от силы наберётся.
AVK>Он не про правила, а про количество их применений в коде.

Тем более перегнул палку. С# код от силы в 2 раза меньше чем Си++ код. Откуда же там в 1000 разбольше правил? Даже в 100 раз?

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

mdw>Виноват.
mdw>В любом случае, спасибо за релевантный и вежливый коментарий.
mdw>А что движок позволяет редактировать собственные сообщения?

Нет. Только модератору. Но местный модер сейчас имеет плохую связь и на сайт не вылезает в онлайне.

Есть другая возможность. Ответь еще раз без оверквотинга, а на тех сообщениях поставим бомбу. Я свою уже поставил.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>Тем более перегнул палку. С# код от силы в 2 раза меньше чем Си++ код. Откуда же там в 1000 разбольше правил? Даже в 100 раз?

Блин, сколько у тебя в проекте раз применены обоертки и всевозможные холдеры?

У меня на парсер ровно один using. В других проектах еще с десяток наберется.

... << RSDN@Home 1.1.4 beta 2 >>

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

A>Тем более перегнул палку. С# код от силы в 2 раза меньше чем Си++ код. Откуда же там в 1000 разбольше правил? Даже в 100 раз?

Оттуда что выделения памяти в программе как правило как минимум на порядок больше, чем выделения неуправляемых ресурсов.

... << RSDN@Home 1.1.4 beta 2 rev. 157>>

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

VD>Блин, сколько у тебя в проекте раз применены обёртки и всевозможные холдеры?

А с каких это пор обёртка — правило?
По твоему чтобы применять std::string вместо LPTSTR надо очень мучатся?
Или CHandle и HANDLE можно перепутать?

Правило, Влад, это например писать ++i вместо i++. Внешне почти одно и тоже, но в 90% случаев первое быстрее. Вот это правило, а обёртка не правило.

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

AVK>Оттуда что выделения памяти в программе как правило как минимум на порядок больше, чем выделения неуправляемых ресурсов.

1 правило — не пользоваться голыми указателями.
Что ещё?

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

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

VD>>Блин, сколько у тебя в проекте раз применены обёртки и всевозможные холдеры?

A>А с каких это пор обёртка — правило?

С тех самых как его приходится соблюдать. Другими словами нужно напрягаться чтобы не нарушить соглашения. А это уже потенциальная проблема. И чем больше случаев где это нужно делать, тем потенциально больше ошибок можно наворотить.

A>По твоему чтобы применять std::string вместо LPTSTR надо очень мучатся?

При каждом применении. А зачастую std::string вобще не приминим, и прийдется крутиться между ним и LPTSTR. LPTSTR кстати, еще одно никому не нужное соглашение. Вот в дотнете и сделали просто — string и никаких вариаций.

A>Или CHandle и HANDLE можно перепутать?

Легко. Подставил одно вместо другого и приплыл. А если их нет, то и ошибиться нельзя.

A>Правило, Влад, это например писать ++i вместо i++.

Это не правило. Это предпочтение.

A> Внешне почти одно и тоже, но в 90% случаев первое быстрее.

Ерунду то не говрои. Компилятору пофигу где ты что поставишь. В АСТ даже понятия такого нет. Это всего лишь определяет когда выполнять операцию сложения.

A> Вот это правило, а обёртка не правило.

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

... << RSDN@Home 1.1.4 beta 2 >>

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

AVK>Оттуда что выделения памяти в программе как правило как минимум на порядок больше, чем выделения неуправляемых ресурсов.

Порядок — это не смешно. 3-4 порядка будет ближе к истене. Я тут глянул сколько юсингов в парсере... так вот один. А сколько там выделений памяти пожешь себе представить.

... << RSDN@Home 1.1.4 beta 2 >>

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

VD>Легко. Подставил одно вместо другого и приплыл. А если их нет, то и ошибиться нельзя.
A>>Правило, Влад, это например писать ++i вместо i++.
VD>Это не правило. Это предпочтение.

A>> Внешне почти одно и тоже, но в 90% случаев первое быстрее.
VD>Ерунду то не говрои. Компилятору пофигу где ты что поставишь. В АСТ даже понятия такого нет. Это всего лишь определяет когда выполнять операцию сложения.

Влад, если ты утверждаешь, что i++ и ++i выполняются за одинаковое время значит ты не знаешь Си++. А что за смысл тогда что-то обсуждать?

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

VD>У тебя случаем не разделение личности? Я говорил о адонзе и его проектах.

Влад, а адонц! К тому же что-за снисходительность к размерам моих проектов?

LM>> Использовать правильные идиомы и соглашения без исключений, и все будет в порядке.
VD>А еще и без исключений. Ню-ню. Очень правильно. Поделись что пишешь то?

По моему понятно, что человек говорил не об отсутсвии exceptions(try/catch), а о том, что идиомы и соглашения должны применятся везде, без отступлений от идиом и соглашений.

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

AVK>>Оттуда что выделения памяти в программе как правило как минимум на порядок больше, чем выделения неуправляемых ресурсов.

A>1 правило — не пользоваться голыми указателями.
A>Что ещё?

Он не про правила, а про количество их применений в коде.

... << RSDN@Home 1.1.4 beta 2 rev. 157>>

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

mdw>А что движок позволяет редактировать собственные сообщения?

Как редактировать я не нашел, но удалять позволяет. Нажимаешь на кнопку с бомбой, там выбираешь пункт "удалить сообщение". Удаляешь его, а вместо него потом кладешь исправленное.

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

mdw>А драйвера всех видов и мастей, это тоже не Windows? Произвольно за/выгружаемые, написанные разными производителями, не имевшие представления друг о друге, работающие в многоуровневой связке (например файловая система: от драйвера накопителя и до самых до верхов)

mdw>Простите но Ваша убежденность в необходимости сборщика мусора, немного похожа на релегиозную

А эти самые драйверы общаются между собой передавая друг другу полиморфные переменные или они все-таки как-то по старинке — не ОО? Что-то мне мерещится, что при написании драйверов Windows полиморфизмом не шибко пользуются...

Здравствуйте, S.Yu.Gubanov, Вы писали:

mdw>>А что движок позволяет редактировать собственные сообщения?

SYG>Как редактировать я не нашел, но удалять позволяет. Нажимаешь на кнопку с бомбой, там выбираешь пункт "удалить сообщение". Удаляешь его, а вместо него потом кладешь исправленное.

"Удалить как ошибочное", тогда удалится сразу.

... << RSDN@Home 1.1.4 beta 2 rev. 159>>

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

K>Передают указатели на функции или структуры с указателями на функции. Т.е. кристально чистый полиморфизм ручной работы.

В общем случае это опасно: передал он внешнему миру указатель на свою внутреннюю структуру. Как теперь он может принять решение об уничтожении этой структуры, откуда он может знать работает внешний мир с тем указателем или больше не работает... априори о внешнем мире ему не известно ничего.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Передают указатели на функции или структуры с указателями на функции. Т.е. кристально чистый полиморфизм ручной работы.

SYG>В общем случае это опасно: передал он внешнему миру указатель на свою внутреннюю структуру. Как теперь он может принять решение об уничтожении этой структуры, откуда он может знать работает внешний мир с тем указателем или больше не работает... априори о внешнем мире ему не известно ничего.

Ничего не поделаешь программирование вообще опасное занятие.
Более того драйвер и не должен принимать решение. С какой это стати? Если вызывающий код запрашивает ресурс то он же его и освобождает.

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

K>Более того драйвер и не должен принимать решение. С какой это стати? Если вызывающий код запрашивает ресурс то он же его и освобождает.

Ну тогда нечего приводить драйверы Windows как пример компонентной среды. В данном случае они выступают просто в роли внешних пассивных библиотек.

Здравствуйте, S.Yu.Gubanov, Вы писали:

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

K>>Более того драйвер и не должен принимать решение. С какой это стати? Если вызывающий код запрашивает ресурс то он же его и освобождает.

SYG>Ну тогда нечего приводить драйверы Windows как пример компонентной среды. В данном случае они выступают просто в роли внешних пассивных библиотек.

Хм. давайте посмотрим поближе:
Драйвера:
1) Динамически загружаются
2) Могут реализовывать входящие-исходящие интерфейсы

Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.

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

K>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.

Типичные но не все. Кроме того слово "компонент" очень широко в своем смысле. Да, конечно, в каком-то смысле этого слова данная система "компонентна". Но драйверы Windows не компонентны в смысле Компонентно ориентированного программирования (КОП).
Определение КОП (данное Клеменсом Шиперски еще 10 лет назад) таково:

КОП = ООП
+ модульность (включая упрятывание информации и позднее связывание модулей, т.е. возможность подгружать необходимые модули в процессе выполнения программы, а не заранее, как это обычно делается в старых системах программирования)
+ безопасность (статический контроль типов переменных и автоматическое управление памятью)
— наследование через границы модулей.

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

Компонентно-ориентированное программирование возникло как своего рода дисциплина, т.е. набор определенных ограничений, налагаемых на механизм ООП, когда стало ясно, что бесконтрольное использование ООП приводит к проблемам с надежностью больших программных комплексов.

Цитата взята с сайта:
http://www.inr.ac.ru/~info21/info/qtocop.htm

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

S>Hello, S.Yu.Gubanov!
S>You wrote on Thu, 19 Aug 2004 10:53:43 GMT:

S>Что-то фигня у вас какая-то получается. Наследование к типам, вообще-то, не
S>привязано. Делаю я, скажем, subclassing TreeView — это в чистом виде
S>наследование моего триконтрола от виндового. При этом какого он там типа в
S>comctl32.dll и класс ли это вообще (в С++ терминах), меня совершенно не
S>интересует.

Есть подозрение, что вы путаете наследование типов и наследование объектов.
Subclassing — классическое наследование объекта. И к типам не имеет отношения.

Hello, xvost!
You wrote on Thu, 19 Aug 2004 11:42:40 GMT:

S>> Что-то фигня у вас какая-то получается. Наследование к типам,
S>> вообще-то, не привязано. Делаю я, скажем, subclassing TreeView — это в
S>> чистом виде наследование моего триконтрола от виндового. При этом
S>> какого он там типа в comctl32.dll и класс ли это вообще (в С++
S>> терминах), меня совершенно не интересует.

x> Есть подозрение, что вы путаете наследование типов и наследование
x> объектов.

Есть подозрение, что это S.Yu.Gubanov путает

x> Subclassing — классическое наследование объекта. И к типам не имеет
x> отношения.
Вот и я о том же. Наследование типов к виндовым драйверам и оконной системе
отношения не имеет. Как, впрочем, и к ООП. Оно, собственно говоря, вообще
является фичей конкретного языка.

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 beta

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

K>Компонентны-по полной программе. Драйвер можно запустить без перезагрузки системы, а другая компонентность здесь не требуется. Все остальные требования тоже соблюдены кроме автоматического контроля памяти.
+1

Кроме того, зачем нам автоматический контроль, если в данном контексте он нам не нужен? От этого система более убогой не становится. А если драйвер совсем кривой то думаю поведение BSOD система всегда сможет правильно воспроизвезти, в его отношении

Так что на заданном уровне, я согласен, система является компонентной.

... << RSDN@Home 1.1.4 beta 2 rev. 164>>

Здравствуйте, S.Yu.Gubanov, Вы писали:

K>>Это и есть типичные признаки компонентности т.е. динамическое связывание реализации с интерфейсом.

[...цитата поскипана...]

ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...

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

ГВ>ИМХО, определение неплохое, но накладывает много дополнительных ограничений на понятие "компонент", а потому и вызвает разночтения. Вот назвали бы как-нибудь "элемент среды, управляющей ресурсами" — не было бы разночтений. А так — берут широко известный термин и прикручивает к нему невесть что. Бардак-с...

Да, действительно, с тех пор как было придумано КОП (более 10 лет назад) термин "компонент" чуть ли не каждый стал трактовать по своему не утруждая себя придумать другой термин. Вот и бардакс..

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

S>Наследование к типам, вообще-то, не привязано.

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

Hello, S.Yu.Gubanov!
You wrote on Mon, 23 Aug 2004 06:46:44 GMT:

SG> Там имелось в виду, что в одном модуле пишется интерфейс, а в другом
SG> модуле целиком пишется реализация.

Какая разница? Интерфейс вообще может быть реализован в трех-четырех модулях
для разных языков.

SG> Реализация не экспортируется — она скрыта от внешнего мира. Модуль
SG> экспортирует только полиморфные переменные (с заданным в том первом
SG> модуле интерфейсом).

Допустим, написал я свой драйвер файловой системы — реализация никуда не
экспортируется, интерфейс к новой файловой системе предоставляется все теми
же CreateFile/WriteFile/ReadFile. Чем не компонента?

SG> Таким образом, модули общаются между собой передавая друг другу не сами
SG> объекты, а полиморфные переменные связанные с этими объектами.

Этому условию замечательно соответсвуют оконная подсистема виндов, API
работы с файлами и куча всего еще. В роли "полиморфной переменной" в этом
случае выступают HWND и HANDLE.

SG> Слово
SG> "наследование" было употреблено в том смысле, что во многих языках
SG> программирования реализация интерфейса сводится к наследованию от
SG> абстрактного класса, а класс — это просто один из типов.

Ну раз уж ты заговорил о парадигмах программирования, то неплохо было бы
обходится без привязки к конкретным языкам.

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 beta

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

S>Чем не компонента?

Компонент чего?
Может ли обычное виндозное пользовательское приложение напрямую запускать Вашу программу или же все-таки Ваша программа должна работать в режиме ядра виндос?
Вот в оберонах драйверы — это, действительно, компоненты так как там нет разницы между модулями операционки и обычными пользовательскими модулями — все они совершенно эквивалентны.

Вот как устроена обычная допотопная операционка типа виндос или юникс:

+----------------+   +----------------+      +----------------+
| Application 1  |   | Application 2  |  ... | Application N  |
+----------------+   +----------------+      +----------------+
        |                   |                        |
        |                   |                        |
        |    +------------------------------+        |
        +----|       Runtime System         |--------+
             +------------------------------+
                            |
                            |
   +------------------------------------------------------+
   |                                                      |
   |                                                      |  
   |                 Operating System                     |
   |                                                      | 
   |                                                      | 
   +------------------------------------------------------+
                            |
                            |
             +------------------------------+
             |           Hardware           |
             +------------------------------+

А вот как устроена оберонистая Aos BlueBottle:

+----------------+   +----------------+      +----------------+
|    Module 1    |   |    Module 2    |  ... |    Module N    |
+----------------+   +----------------+      +----------------+
        |                   |                        |
        |                   |                        |
        |    +------------------------------+        |
        +----|       Runtime System         |--------+
             +------------------------------+
                            |
             +------------------------------+
             |           Hardware           |
             +------------------------------+

Module_i — это модули операционки + модули системных сервисов + модули пользователей; между всеми ними нет никакой принципиальной разницы — вот Вам пожалуйста компонентная система.

*Runtime System — это среда исполнения программ.

Hello, S.Yu.Gubanov!
You wrote on Mon, 23 Aug 2004 14:41:55 GMT:

S>> Чем не компонента?

SG> Компонент чего?

Операционной системы, естественно.

SG> Может ли обычное виндозное пользовательское приложение напрямую
SG> запускать Вашу программу или же все-таки Ваша программа должна работать
SG> в режиме ядра виндос?

Противопоставление тут неуместно. Во-первых, не все драйвера работают в
режиме ядра, во-вторых, бывают загружаемые по требованию драйвера, в
третьих, я говорил не только не только про драйвера, но и про оконную
подсистему. И наконец — причем тут kernel mode? Ну работает драйвер в режиме
ядра, и какому критерию КОП это мешает?

SG> Module_i — это модули операционки + модули системных сервисов + модули
SG> пользователей; между всеми ними нет никакой принципиальной разницы -
SG> вот Вам пожалуйста компонентная система.

Ну и в чем принципальная разница между comctl32.dll и mycoolcontrol.dll? Или
хотя бы в чем принципиальная разница между драйвером и пользовательским
модулем?

With best regards, Sergey.

Posted via RSDN NNTP Server 1.9 beta

От:	S.Yu.Gubanov	http://sergey-gubanov.livejournal.com/
Дата:	27.07.04 10:01
Оценка:	6 (1) -11

От:	S.Yu.Gubanov	http://sergey-gubanov.livejournal.com/
Дата:	27.07.04 12:27
Оценка:	4 (3) -4

	От:	WolfHound
	Дата:	29.07.04 15:39
	Оценка:	1 (1) +1

От:	S.Yu.Gubanov	http://sergey-gubanov.livejournal.com/
Дата:	27.07.04 08:00
Оценка:

От:	adontz	http://adontz.wordpress.com/
Дата:	13.08.04 02:38
Оценка:	21 (3) +1

От:	VladD2	www.nemerle.org
Дата:	14.08.04 02:04
Оценка:	+5

	От:	remission
	Дата:	29.07.04 20:16
	Оценка:	31 (2) +2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	31.07.04 23:52
Оценка:	3 (1) +1

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	29.07.04 10:24
Оценка:	+1 -1

От:	xvost	http://www.jetbrains.com/company/people/Pasynkov_Eugene.html
Дата:	13.08.04 13:27
Оценка:

	От:	Kluev
	Дата:	28.07.04 11:53
	Оценка:	+2

	От:	Kluev
	Дата:	30.07.04 10:32
	Оценка:

	От:	degor
	Дата:	28.07.04 09:18
	Оценка:	+1

	От:	degor
	Дата:	28.07.04 10:32
	Оценка:	+1