Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Что-то я не совсем понимаю. А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?
...
ГВ>Там приведена довольно подробная аргументация по этом поводу. И сказано, кстати, что к GC она не имеет никакого отношения.
SYG>демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".
Почему же кривой все верно написано. Вы предложили избавится от класса Абстрактный агрегат, но чтобы от него избавится необходимо в каждом классе продублировать его функционал. Т.е в каждом классе прийдется иметь список жен детей отцов и матерей. Т.е. посути либо копи-пасте, либо делаем общий базовый класс. Но общий базовый класс делать бесмысленно т.к. нет смысла держать копию агрегата в каждом классе. Действительно представте себе машину в которой каждая деталь сдержит всю машину (вернее копию ссылок на все агрегаты). Имхо это криво не подецки. Гораздо лучше иметь агрегат как отдельный обьект а в нем уже содержать все необходимые ссылки. И в каждом обьекте ссылка на агрегат. Так будет проще и лучше в любой системе независимо есть там сборщик мусора или нет.
ЗЫ. А то что вы написали про экономию на одном классе то поверьте мне на слово (или проверьте) что можно сэкономит гораздо больше простым переходом от BEGIN-END к {}
ЗЫЗЫ: А если серьезно то рекомедую попрограммировать годика три для начала в реальном комерческом проекте. Это очень поможет.
ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Да, испытывает. Например, из-за того, что в finally-блоке нужно прописывать всё то, что можно не писать на языке с детерминированным уничтожением объектов. Отсюда система на Java может оказаться раз 5 больше по объёму, чем аналог на C++.
Но почему-то на практике оказывается в пять раз меньше.
ГВ> Сдаётся мне, что не всё так просто. ИМХО, нужно освобождать свой разум от заблуждений, что что-то может быть в компьютере "бесплатно".
Сдается мне, что компьютеры тут не причем. Бесплатный сыр бывает только...
ГВ>Что-то я не совсем понимаю. А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?
В сложности и объеме работ. А так конечно нет проблем. Так же как нет проблем любой софт сделать на ассемблере.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Kluev, Вы писали:
K>ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.
Гы. Именно так (насколько я знаю) и поступаю все разработчики свербольших микросхем вроде транзисторов. Они делять яего на виртуальные компоненты с четким интерфейсом и уже на базе этих компонентов делают более большие блоки.
В общем, компонет не обязан быть боьшим. А вот интерфейс действительно лучше иметь обозримых размеров.
Тяга к укрупнению обычно связана с проблемами скрости. В дотнете, например, таких проблем нет. По этому можно легко создавать компоненты любых размеров. Собственно любой класс в дотете — это компонент.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
K>Но общий базовый класс делать бесмысленно т.к. нет смысла держать копию агрегата в каждом классе. Действительно представте себе машину в которой каждая деталь сдержит всю машину (вернее копию ссылок на все агрегаты).
Там все объяснено (для деталей машин этот паттерн не применим), если Вы что-то не поняли, то пишите возражения там, а не здесь. Зачем в двух ветках обсуждать одно и тоже?
K>ЗЫЗЫ: А если серьезно то рекомедую попрограммировать годика три для начала в реальном комерческом проекте. Это очень поможет.
Согласен. Я пока только 2 года работаю программистом, и за это время много что понял по сравнению со своим начальным уровнем. К концу третьего года пойму еще больше.
K>ЗЫЗЫЗЫ: Я вначале тоже любил писать все в компонентном стиле, но потом понял что писать надо не компонентно, а правильно. ИМХО компонент должен из себя представлять кусок большой функционала с относительно узким интерфейсом. Пример процессор. Интерфейс весьма узок: 300 проводов, начинка миллионы транзисторов. Абсолютно бесмысленно пытатся писать компонентно на уровне транизисторов, на этом уровне монолитная архитектура самое лучшее.
Не знаю как у Вас, но у меня монолитные архитектуры умещаются в голове только если количество кода не превышает примерно 5'000 строчек кода. Если монолитная система имеет более 10'000 строчек кода, то я психически не выдерживаю и начинаю ее переписывать.
Каковы размеры Ваших монолитных систем?
Что касается характерного размера одного модуля: начинается примерно от 100-200; оптимально — 500 строчек, максимум 2'000 строчек кода.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Не знаю как у Вас, но у меня монолитные архитектуры умещаются в голове только если количество кода не превышает примерно 5'000 строчек кода. Если монолитная система имеет более 10'000 строчек кода, то я психически не выдерживаю и начинаю ее переписывать.
SYG>Каковы размеры Ваших монолитных систем?
Около миллиона строк.
Скорее всего мы по разному понимаем слово монолитная. Монолитная для меня это когда интерфейс не отделен от реализации. Т.е. обычная библиотека классов которая линкуется статически, компонентность предполагает одтеление интерфейса от реализации, т.е. под одним интерфейсом может скрыватся несколько реализаций. Как следствие этого компонентнвй обьект может быть создан только динамически т.к. используемая реализация не известна компилеру-компоновщику, и юзатся он может только через интерфейс. Такой подход во многих случаях просто не нужен. Т.е. можно иметь несколько хорошо спроектированных библиотек классов (которые потихоньку эволющионируют) и на их базе создется программа. Т.к. все линкуется статически получается монолитная архитектура (один экзешник, куда уж монолитнее)
ЗЫ: И ограничений на количество строк в проекте вобщем-то нет.
Здравствуйте, Kluev, Вы писали:
SYG>>Каковы размеры Ваших монолитных систем? K>Около миллиона строк.
Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Kluev, Вы писали:
SYG>>>Каковы размеры Ваших монолитных систем? K>>Около миллиона строк.
SYG>Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?
Это как же их учтешь? после развертки? нет обычный код. включая фортрановский.
Компилируется если с нуля минуты три. В релизе поболее.
Здравствуйте, Kluev, Вы писали:
SYG>>Миллион вручную написанных строк или это после учета развертки шаблонов? А сколько времени все это хозяйство в совокупности компилируется, если не секрет?
K>Это как же их учтешь? после развертки? нет обычный код. включая фортрановский. K>Компилируется если с нуля минуты три. В релизе поболее.
Как учесть-то? Ну, это просто, типа как Borland C++ Builder 6.0 когда компилирует, то в окошке показывает сколько строчек кода он уже скомпилировал. Причем показывает именно реальное количество, то есть то которое получается после разворачивания шаблонов. Смотришь и глаза из орбит вылазиют — в проге которуя я однажды сопровождал было 19 миллионов строчек, хотя вручную написанных в тысячу раз поменьше было, остальное = Борландовская VCL + шаблоны всякие.
Здравствуйте, Kluev, Вы писали:
K>Скорее всего мы по разному понимаем слово монолитная. Монолитная для меня это когда интерфейс не отделен от реализации. Т.е. обычная библиотека классов которая линкуется статически, компонентность предполагает одтеление интерфейса от реализации, т.е. под одним интерфейсом может скрыватся несколько реализаций. Как следствие этого компонентнвй обьект может быть создан только динамически т.к. используемая реализация не известна компилеру-компоновщику, и юзатся он может только через интерфейс. Такой подход во многих случаях просто не нужен. Т.е. можно иметь несколько хорошо спроектированных библиотек классов (которые потихоньку эволющионируют) и на их базе создется программа. Т.к. все линкуется статически получается монолитная архитектура (один экзешник, куда уж монолитнее)
Здравствуйте, 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 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Разварачиваются не шаблоны, а макросы. Шаблоны работают на уровне АСТ, а не текста.
А includ-ы текстовых файлов работают на каком уровне?
Какая разница на каком уровне что работает. Общее реально полученное после всех подстановок макросов, шаблонов, инклюдов количество строчек составляет десятки миллионов. Пусть Вы их собственными глазами и не видите, но они все равно подразумеваются.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>А includ-ы текстовых файлов работают на каком уровне?
Это макросы. SYG>Какая разница на каком уровне что работает.
Большая. Шаблон!=макрос. Шаблоны не генерируют текст. Они не порождают дополнительные строки. Этим занимается препроцессор. А шаблонами ворочает компилятор. SYG>Общее реально полученное после всех подстановок SYG>макросов,
Раскрытие макроса колличество строк не увеличивает. Макрос раскрывается в одну строку. Да длинною но одну.
Вот работа макроса
SYG>шаблонов,
Шаблоны работают на уровне АСТ текст не производят вобще. SYG>инклюдов
Вот они и плодят строки в каждой единице трансляции SYG>количество строчек составляет десятки миллионов.
При грамотной организации проекта получить больше полумиллиона строк в одной единице трансляции (единица трансляции это один *.cpp файл и все что в него проинклудили) довольно трудно. Причем подавляющие колличество кода будет вынесено в так назаваемые прекомпилированные заголовки(PCH). Те реально при компиляции одной единици трансляции обрабатывается несколько тысячь строк. А те пол миллиона строк лежат в прекомпилированном виде.
Не смотря на то что багланды вродебы поддерживают PCH де-факто они "работают" весьма хреново. SYG>Пусть Вы их собственными глазами и не видите, но они все равно подразумеваются.
Ну почемуже не вижу? Если захочу то могу и увидить. И даже иногда смотрю когда макросы отлаживаю.
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Ael, Вы писали:
Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, degor, Вы писали:
D>Да, если система не желает полагаться на выполнение правил разработчиками компонентов, единственным средством контролировать время жизни объектов остается общесистемный GC.
Разработка любой системы так или иначе завязана на выполнение разработчиками каких-то правил.
Писать с отступами например. Ну подумаешь правилом больше, правилом меньше. Зри в корень!
Либо на Х языке что-то можно написать, либо нельзя. И только это поределяет язык Х, а удобсвто это на самом деле весьма субъективыный фактор.
Здравствуйте, 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, ты не против?
Похоже, 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# таких как метаинформация и проч. я не спорю, так как это действительно хорошо.
По-моему, причина таких настроений заключается в том, что GC в таких языках, как Java и C#, является чужеродной сущностью, внесенной в семантику Си++, чужеродной даже по синтаксису. Действительно, если создание объекта выглядит как
Object a = new Object;
то естественно задать вопрос: а когда этот объект будет удален?
Однако если посмотреть на другие языки, с давней традицией GC, прежде всего функциональные (Lisp, ML, Erlang) и, возможно, Smalltalk, то там этого вопроса просто не возникает. Там действительно память — не ресурс, а "объекты" — не вещи, которые нужно создавать и разрушать. GC применяется только к значениям, а не к "объектам", и упрекать их за то, что в них не проводится явное освобождение памяти — все равно что упрекать Си++, что в нем не проводится явное освобождение, например, литерала "Hello, world\n", когда он становится больше не нужным во всем известной программе.
А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?
