Здравствуйте, template, Вы писали:
T>Здравствуйте, oRover, Вы писали:
R>>Здравствуйте, template, Вы писали:
T>>>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.
T>>>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
T>>>Жду Ваших высказываний
R>>почитай о чистильщике мусора и о том, как GAC работает...
T>Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.
Вот это утверждение как раз и говорит об опыте... Не слишком большом.
Здравствуйте, template, Вы писали:
T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.
T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
T>Жду Ваших высказываний
То что ты видишь в списке задач это зарезервировання память http://www.gotdotnet.ru/default.aspx?s=board_search&d_no=0&text=SetProcessWorkingSetSize
которая к Commit памяти не имеет отношение. Как и во всех менеджерах памяти резервируется достаточно большой блок памяти. Я тут в тестах и более 10 000 000 объектов обрабатываю и с валью типами скорость даже выше Native компиляторов. А вот справиться с дефрагментацией памяти можно только по принципу работы GC и на это ушло огромное количество времени и тестов.
По подходу создания универсальных нетипизированных классов тут я с тобой согласен, но в новой версии VS.Net есть дженерики, да и свои руки есть.
А писАть можно на чем угодно, но почему то мне кажется, что время Native компиляторов прошло, и этому есть огромное количество причин.
А неленивые пишут на АСМе
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Hacker_Delphi, Вы писали:
H_D>>Для будующих версий сейчас это значение на любом FrameWork == 2...
AVK>А у CF?
Вроде тоже.. я Windows Developer Magazine это читал... они будут MaxGeneration > 2 делать тока при переходе на совсем другие аппаратные платформы... я так понял...
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, template, Вы писали:
T>Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.
Не это называется баундчекером и бессонными ночами.
А вооще, тут не в этом дело. Главное в GQ (да и в других фишках дотнета) — это то что минимизируется необходимость делать лишние действия. Избавляясь от задачи контроля памяти ты не только получаешь более надежный кода, но и можешь потратить высвобожденное время на полезную работу.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности". ВВ>В общем нету детерминированного уничтожения в дотнете, нету.
Насколько мне извесно принудительный ЖЦ уничтожает объекты во всех поголениях. Даже два раза вызывать не нужно.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Hacker_Delphi, Вы писали:
H_D>... при каждом Collect ссылка уменьшает свое поколение...
Все наоборот. При каждом коллекте не уничтоженная ссылка увеличивает свое поколение. Просто сама сборка мусора как раз и заключается в копировании объектов из одного хипа в другой. Всего есть три хипа. Они то поколениями и называются. Рассчет таков: если объект пережил сборку мусора, то вероятность, того что он будт жить и дальше резко повышается. Таким образом в первом хипе жинь бурлит, а в последнем сидят один пенсионеры и инвалиды.
H_D>а именно два — потому, что я-то знаю, что больше 2-х не бывает
Гы. Их три. От 0 до 2.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, template, Вы писали:
T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.
T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
T>Жду Ваших высказываний
Насколько я понял платформа то предназначена для серверных решений (в основном). А нормальному серверу что твои 24 метра, что 240 — это тьфу... А клиента пиши на том же MFC, никто не мешает.
Тут же дело в самой идее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Hacker_Delphi, Вы писали:
H_D>>... при каждом Collect ссылка уменьшает свое поколение...
VD>Все наоборот. При каждом коллекте не уничтоженная ссылка увеличивает свое поколение. Просто сама сборка мусора как раз и заключается в копировании объектов из одного хипа в другой. Всего есть три хипа. Они то поколениями и называются. Рассчет таков: если объект пережил сборку мусора, то вероятность, того что он будт жить и дальше резко повышается. Таким образом в первом хипе жинь бурлит, а в последнем сидят один пенсионеры и инвалиды.
H_D>>а именно два — потому, что я-то знаю, что больше 2-х не бывает
VD>Гы. Их три. От 0 до 2.
ну короче, мой код гарантировано прибьет все "мертвые" ссылки... независимо от генерации.
ЗЫ Насколько я понял, при сборке поколение учитывается только для "слабых" ссылок... "мертвые" объекты убиваются сразу...
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности". ВВ>>В общем нету детерминированного уничтожения в дотнете, нету.
VD>Насколько мне извесно принудительный ЖЦ уничтожает объекты во всех поголениях. Даже два раза вызывать не нужно.
Нужно... для сбора слабых ссылок... у них точно при принудиловке тока поколение уменьшается...
... << RSDN@Home 1.1 beta 2 >>
Если при компиляции и исполнении вашей программы не происходит ни одной ошибки — это ошибка компилятора :)))
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности". ВВ>>В общем нету детерминированного уничтожения в дотнете, нету.
VD>Насколько мне извесно принудительный ЖЦ уничтожает объекты во всех поголениях. Даже два раза вызывать не нужно.
А если у одного из объектов в хипе есть финалайзер, сам по себе объект ссылается на другие объекты и пр. — то вся эта братия просто переходит в другое поколение.
К тому возьмем чисто практический момент. Насоздавай мусора и вызови ЖЦ. Что-то я сомневаюсь, что память освободится.
Здравствуйте, Serginio1, Вы писали:
S> которая к Commit памяти не имеет отношение. Как и во всех менеджерах памяти резервируется достаточно большой блок памяти. Я тут в тестах и более 10 000 000 объектов обрабатываю и с валью типами скорость даже выше Native компиляторов. А вот справиться с дефрагментацией памяти можно только по принципу работы GC и на это ушло огромное количество времени и тестов.
А вот не верю. И все.
И про скорость и про GC.
S> А писАть можно на чем угодно, но почему то мне кажется, что время Native компиляторов прошло, и этому есть огромное количество причин.
Причины в студию, плиииз.
S> А неленивые пишут на АСМе
Здравствуйте, c-smile, Вы писали:
S>> А писАть можно на чем угодно, но почему то мне кажется, что время Native компиляторов прошло, и этому есть огромное количество причин. CS>Причины в студию, плиииз.
Я бы сказал, что под _винду_ время нативных компиляторов и правда прошло. А пример здесь можно найти достаточно.
и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
) их будет меньше. 
