Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Здравствуйте, Ael, Вы писали:
Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>Спасибо!
Здравствуйте, S.Yu.Gubanov, Вы писали:
Ael>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>>Спасибо!
SYG>А противоположную по смыслу ссылку не желаете?
Здравствуйте, Sergey J. A., Вы писали:
SJA>Здравствуйте, S.Yu.Gubanov, Вы писали:
Ael>>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>>>Спасибо!
SYG>>А противоположную по смыслу ссылку не желаете?
SJA>Давай. Кто-нибудь да пожелает. Я например....
А далеко ходить и не надо, вон прямо в соседней ветке...
Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
SYG>Теперь, собственно, при чем тут сборщик мусора. Рассмотрим более общую ситуацию. Пусть есть многомодульная система. Большинство модулей на момент написания не имели никакого представления друг о друге. Модули — единицы компиляции и исполнения программы, они могут динамически загружаться/выгружаться во время работы Программы. Под Программой, можно понимать всю операционную систему, а модули — ее расширения. Модули создают внутри себя объекты и в виде полиморфных переменных передают их для использования другим модулям, те модули, в свою очередь, могут передать эти полиморфные переменные третьим модулям и т.д.. Модуль создавший обьект и отдавший его другому модулю в принципе понятия не имеет кто еще пользуется этим объектом и как долго он это намерен делать. А значит модуль-создатель в принципе не может нести ответсвенность за уничтожение им созданного объекта. Но никакой другой модуль тоже в принципе не может нести ответсвенность за уничтожение чужого объекта. Подсчет ссылок на объект проблемы не решает поскольку, в общем случае, возможны замкнутые петли (циклические) ссылки объектов друг на друга. Утечка памяти в многомодульных системах неизбежна по принципиально неразрешимым причинам. Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
SYG>Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.
SYG>Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям? SYG>В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Ael, Вы писали:
Ael>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>>Спасибо!
SYG>А противоположную по смыслу ссылку не желаете?
Я хочу услышать, то что мне надо
А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой, хотя конечно очень интересно. Но получить четко сформулированное обоснование подобных усилий было бы неплохо.
SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
Ааафигеть можно! Как же многоуважаемый сэр объясняет существование операционной системы Windows, и таких продуктов как Microsoft Office?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>А далеко ходить и не надо, вон прямо в соседней ветке... SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
Бред сивой кобылы. Взять к примеру Catia (это CAD такой) имеет модульную (компонентную) архитектуру. Причем состоит не из нескольких компонентов, а скорее из нескольких сотен. Написан на С/С++
SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=725451&only=1
SYG>>Объясняю еще раз. Вот представьте себе что у Вас есть тысяча динамически загружаемых бинарных модулей все от разных производителей. Модули в процессе своей работы создают объекты (каждый модуль создает свои объекты). Для взаимодействия друг с другом эта тысяча модулей обмениваются друг с другом объектами (в виде полиморфных переменных). Объекты могут ссылаться друг на друга произвольным способом (то есть возможны циклические ссылки объектов из разных модулей друг на друга). КТО и КОГДА по Вашему должен вызывать delete для ненужных больше объектов? КАК узнать что объект больше никем не используется? Счетчик ссылок для этих целей не подходит так как возможны петлевые взаимоссылки. Учтите еще что на момент написания модуля НЕИЗВЕСТНО сколько и каких модулей еще будет в той ОС в которой он будет работать. Ну что? Дошло до Вас что задача вызова delete НЕРАЗРЕШИМА на момент написания модуля? Задача освобождения ресурсов может быть решена только ДИНАМИЧЕСКИ во время работы программы, а такая динамическая штуковина называется — СБОРЩИК МУСОРА.
Это бред не могу себе представить. Если и есть такая система то как правило загружаемые модули редко общаются друг с другом. Например плагины даже и не знают о существовании друг друга. Т.е. такой пробелемы нет в природе. А если там действително все друг на друге заявзано причем модули разных производителей то такую систему и написать-то будет очень проблемматично, т.к. врядли удасца связать все это вместе. Как правило такие системы имеют древовидную архитектуру. Т.е. к ядру подрубаются плагины, и к плагинам подплагины и т.п.
Тот кто написал этот бред наверное и не видел больших систем-то. Даже если и есть такие системы (где все друг на друге) то это мертворожденнные проекты. т.к. такое очень сложно поддерживать и развивать и место ему только на мусорке.
SYG>>Как организована ваша приватная внутримодульная утилизация более не используемых ресурсов — Ваше личное дело и оно не интересует другие модули (можете даже использовать для этого ту ссылку которую привели). Вопрос состоит в другом — как Вы будете принимать решение об уничтожении объектов адреса которых Вы сообщали другим (внешним) модулям? SYG>>В той ссылке описывается доморощенный сборщик мусора работающий только внутри одного модуля. То есть если запустить два экземпляра такой программы, то, соответственно, будет два доморощенных сборщика мусора. Две таких программы не смогут обмениваться объектами друг с другом. Я же говорю об одном единственном на всю ОС сборщике мусора который единолично разруливает все объекты всех модулей системы. В Component Pascal, .NET и Java сборщик мусора всего один на всю систему независимо от того сколько программ (модулей) в этой системе в данный момент загружено. Так понятно?
Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.
Здравствуйте, degor, Вы писали:
SYG>>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
D>Ааафигеть можно! Как же многоуважаемый сэр объясняет существование операционной системы Windows, и таких продуктов как Microsoft Office?
Афигейте, мне то что. А, собственно, что именно надо объяснить? Я разьве говорил что кроме модульных систем никаких других систем не бывает? Конечно бывают как модульные так и не модульные системы, вот, пожалуйста, тот же Windows с Unix-ом не модульные и ничего вроде, нормально работают.
Здравствуйте, Ael, Вы писали:
Ael>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой, хотя конечно очень интересно. Но получить четко сформулированное обоснование подобных усилий было бы неплохо.
Лучше всего почитать первоисточник: Страуструп. Дизайн и эволюция С++. Там мэтр рассказывает, почему и как С++ получился таким — с самого начала и до появления STL. Очень интересное повествование.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, Kluev, Вы писали:
K>Бред сивой кобылы. Взять к примеру Catia (это CAD такой) имеет модульную (компонентную) архитектуру. Причем состоит не из нескольких компонентов, а скорее из нескольких сотен. Написан на С/С++
K>О... Маразм крепчал.
K>Это бред не могу себе представить. Если и есть такая система то как правило загружаемые модули редко общаются друг с другом. Например плагины даже и не знают о существовании друг друга. Т.е. такой пробелемы нет в природе. А если там действително все друг на друге заявзано причем модули разных производителей то такую систему и написать-то будет очень проблемматично, т.к. врядли удасца связать все это вместе. Как правило такие системы имеют древовидную архитектуру. Т.е. к ядру подрубаются плагины, и к плагинам подплагины и т.п.
K>Тот кто написал этот бред наверное и не видел больших систем-то. Даже если и есть такие системы (где все друг на друге) то это мертворожденнные проекты. т.к. такое очень сложно поддерживать и развивать и место ему только на мусорке.
K>Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.
Уважаемый, Ваша реакция неадекватна. Я допускаю, что Вы не вкурсе, что термины "модульность" и "компонент" в рамках компонентно ориентированной парадигмы программирования предложенной Клеменсом Шиперски десять лет назад имеют чуточку не тот смысл что использовали Вы охарактеризовав так программу написанную на С++. Я допускаю что Вы не вкурсе, что уже десятилетие как существуют модульные операционные системы (разные клоны Оберонов). Я допускаю, что Вы не вкурсе того как можно проектировать большие модульные системы и поэтому сомневаетесь в возможности этого: "такую систему и написать-то будет очень проблемматично", "это мертворожденнные проекты". Так же я допускаю, что Вы не вкурсе того что ноги .NET, Java, Inferno+Limbo растут из копирования академически грамотных систем — Оберонов. Я допускаю, что Вы не понимаете почему в модульных системах всегда есть сборщик мусора. Но если Вы этого не знаете или не понимаете, то почему бы Вам вместо того чтобы кидаться словами — "Бред сивой кобылы", просто по человечески спокойно поинтересоваться о том что не знаете?
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>>Единственным выходом из этой ситуации является наличие единого на всю операционную систему полноценного сборщика мусора. Сборщик мусора — это не роскошь, и не фича придуманная для ленивых программистов. Сборщик мусора — это осознанная необходимость. Существование многомодульныех систем, модули которых обмениваются друг с другом объектами, невозможно без одного на всех полноценного сборщика мусора.
Не понял, откуда это следует.
Здравствуйте, Kluev, Вы писали:
K>Опять мимо кассы! Сборщик мусора в НЕТ-е это скорее вынужденное решение. Т.к. если есть хотябы один язык со сборкой мусора то и все прийдется делать со сборкой. Былабы возможность от него бы отказались с радостью.
Точно так же как и от всех языков программирования. Была бы возможность писать программы с помощью мыши, отказались бы от кода вообще.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Ael, Вы писали:
Ael>>А на самом деле — С++ (по сравнению с С#) кажется мне довольно сложной штукой,
AVK>С++ конечно штука сложная, но C# вряд ли сильно проще, скорее наоборот, сложнее.
Обоснуйте, пожалуйста, какие критерии сложности вы используете?
Когда я говорю, что С# для меня проще, я руководствуюсь тем, что после аналогичного периода изучение языка я мог создавать на С# (и на управляемом С++) гораздо более продвинутые приложения, чем я сейчас могу на на неуправляемом С++.
MSDN документация по .NET Framework читается гораздо легче, чем MSDN документация по С++.
При сравнении языков очень трудно дистанцироваться от платформ — опять же контейнеры STD кажуться мне гораздо сложнее, чем System.Collections;
Итак какие критерии сложности?
Здравствуйте, Ael, Вы писали:
Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Да нет таких приемуществ. Ну, разве что рантайм в 20 мег на машину ставить не надо. А так все что можно сделать на С++ можно сделать и на дотнете (хтя бы на том же МС++). Ну, если только драйверы писать нельзя.
ЗЫ
В общем, очердной флэйм.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>А далеко ходить и не надо, вон прямо в соседней ветке... SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
Ну, ну, так уж не невозможно. Тяжело — да. Но КОМ пока никто не отменял.
... << 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
