На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...

Жду Ваших высказываний

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

T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
Нет... просто для оптимизации (!!!) программа берет память с запасом, пока она есть... если тебе потребуется память — она почти мгновенно освободится... для прикола попробуй свернуть свое приложение — объем памяти мифически уменьшится...

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

T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...

T>Жду Ваших высказываний

На мой взгдяд, у Microsoft всегда первый блин комом, потом выходит огромное количество заплаток, обновлений и только потом получается что-то стоящее. .NET относительно новая техология, хотя разработка началась ~ в 98 году , так что, господа, ждите обновлений и патчей, а насчет MFC и WTL согласен... Впрочем, с одной стороной можно писать и на ассемблере программы ; ) , с другой — компьтеры с каждым днем становятся мощнее и производительнее, в общем, есть о чем поговорить, мне бы тоже интересно было бы почитать чужие мнения.
P.S Кстати, а каком разделе находится этот форум, я чего то не нашел

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


T>На мой взгдяд, у Microsoft всегда первый блин комом, потом выходит огромное количество заплаток, обновлений и только потом получается что-то стоящее. .NET относительно новая техология, хотя разработка началась ~ в 98 году , так что, господа, ждите обновлений и патчей, а насчет MFC и WTL согласен... Впрочем, с одной стороной можно писать и на ассемблере программы ; ) , с другой — компьтеры с каждым днем становятся мощнее и производительнее, в общем, есть о чем поговорить, мне бы тоже интересно было бы почитать чужие мнения.

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

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

T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...

T>Жду Ваших высказываний

почитай о чистильщике мусора и о том, как GAC работает...

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

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

T>>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...

T>>Жду Ваших высказываний

R>почитай о чистильщике мусора и о том, как GAC работает...

Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.

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

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

T>>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...
H_D>Нет... просто для оптимизации (!!!) программа берет память с запасом, пока она есть... если тебе потребуется память — она почти мгновенно освободится... для прикола попробуй свернуть свое приложение — объем памяти мифически уменьшится...

Весело... все как ты и сказал. Но мне кажется, что такие маневры как освободил, распределил — не очень хорошо сказываются на производительности.

Мне тут вспомнился случай, кажется на коробке с Visual Studio была фотка мужика с кастылями, которые он протягивает. Похоже MS все еще считает нас инвалидами, для которых просто необходима инвалидное кресло. И полное тому подтверждение это сборщик мусора в .NET. Обидно считать себя ущербным

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


R>>почитай о чистильщике мусора и о том, как GAC работает...

T>Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.

это я по поводу того, почему программа на 24 метра. Что в этом ничего страшного нету. Можешь и сам удалять объекты, а если лениво — за тобой еще и приберут

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

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


R>>>почитай о чистильщике мусора и о том, как GAC работает...

T>>Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.

R>это я по поводу того, почему программа на 24 метра. Что в этом ничего страшного нету. Можешь и сам удалять объекты, а если лениво — за тобой еще и приберут

Каким это образом можно самому удалять объекты?

N> Я бы на счет связи плохого кода и количества заплаток поспорил..
N> Количество пачей свидетельствует о работе групп подержки и чем их больше тем лучше работает компания.. а ошибки в
программах есть всегда.. главное их во время испавлять )

Я это и имел ввиду, на мой взгдяд, майкрософт только поэтому и лидирует (благодаря поддержке, грамотному маркетингу и абсолютной монополии ) .

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

T>На днях попробовал сабж. Первое впечатление восторг. Все так сделано приятно, легко и понятно. Но черт меня дернул заглянуть в список процессов. Увидел я сколько моя первая программа занимает места, я ужасно расстроился — 27МБ. Вы скажите, что сейчас память это не проблема, а я в ответ но моя первая программа ничего не делала, а что будет если я пару таблиц по 100000 записей загружу.

T>Значит это тоже Visual Basic, но с синтаксисом С++ и как всегда конечный пользователь будет расплачиваться за нашу лень, писать программы на MFC или WTL. Последнее мне кстати очень к душе пришлось...

T>Жду Ваших высказываний

Не хочется классиков искажать... Рихтер вроде говорил что размеры первого (да и всех) поколений кучи можно настраивать (или они сами настраиваются) — не помню, но мораль в том что размер, который прога жрёт кажись зависит от размера всей памяти+длины жизни обьектов — так что не всё так полохо. Кстати я тоже запустил своё детище на .НЕТ — 14 метров, вначале опечалился а потом заметил что эта зараза Save.exe жрёт цедых 23 — настроение сразу поднялось

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

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

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


R>>>>почитай о чистильщике мусора и о том, как GAC работает...

T>>>Автоматическая очистка это хорошо, это приятно, НО а зачем мне, тебе, ему голова нужна... Я думаю, что мы сами лучше знаем когда когда что уничтожать. Конечно, на первых этапах могут быть ошибки, но зато потом (это кажется опытом называется) их будет меньше.

R>>это я по поводу того, почему программа на 24 метра. Что в этом ничего страшного нету. Можешь и сам удалять объекты, а если лениво — за тобой еще и приберут

ВВ>Каким это образом можно самому удалять объекты?
ну, достаточно большая часть FCL реализует интерфейс IDisposable, что гарантирует (при необходимости) освобождение ресурсов + всегда ьщжно сделать так:

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
GC.WaitForPendingFinalizers();

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

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

ВВ>>Каким это образом можно самому удалять объекты?
H_D>ну, достаточно большая часть FCL реализует интерфейс IDisposable, что гарантирует (при необходимости) освобождение ресурсов + всегда ьщжно сделать так:
H_D>

H_D>GC.Collect();
H_D>GC.WaitForPendingFinalizers();
H_D>GC.Collect();
H_D>GC.WaitForPendingFinalizers();
H_D>

H_D>после выполнения этого кода гарантировано, что все "мертвые" ссылки будут почищены...

Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности".
В общем нету детерминированного уничтожения в дотнете, нету.

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

ВВ>Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности".
Два раза — потому, что есть так называемые "поколения" ссылок (вроде как generation)... при каждом Collect ссылка уменьшает свое поколение...
а именно два — потому, что я-то знаю, что больше 2-х не бывает
ВВ>В общем нету детерминированного уничтожения в дотнете, нету.
есть... именно как я написал... к тому же уничтожение и не нужно... нужно лишь освобождение ресурсов, для чего и существует паттерн IDisposable + using (c#)...

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

H_D>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Почему гарантировано? На самом деле не факт, и многие на это нарываются. К тому же заметь — ты два раза повторяешь один и тот же код, что уже вызывает серьезные сомнения в "гарантированности".
H_D>Два раза — потому, что есть так называемые "поколения" ссылок (вроде как generation)... при каждом Collect ссылка уменьшает свое поколение...

Ну поколений-то далеко не два. А если в объекте реализован финалайзер или он живет достаточно долго — уверен, что двух раз хватит?

H_D>а именно два — потому, что я-то знаю, что больше 2-х не бывает
ВВ>>В общем нету детерминированного уничтожения в дотнете, нету.
H_D>есть... именно как я написал... к тому же уничтожение и не нужно... нужно лишь освобождение ресурсов, для чего и существует паттерн IDisposable + using (c#)...

Так ведь изначально речь шла именно об уничтожении, на что я и возразил. А освобождение ресурсов вещь совершенно иная, тк все ресурсы к-е таким образом освобождаются — это unmanaged ресурсы

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

ВВ>Ну поколений-то далеко не два. А если в объекте реализован финалайзер или он живет достаточно долго — уверен, что двух раз хватит?
почитай доки от МС там написано, что именно два, а финалайзеров мы ждем как раз каждой четной строкой кода...

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

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

H_D>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Ну поколений-то далеко не два. А если в объекте реализован финалайзер или он живет достаточно долго — уверен, что двух раз хватит?
H_D>почитай доки от МС там написано, что именно два, а финалайзеров мы ждем как раз каждой четной строкой кода...

Ага. А зачем тогда GC.MaxGeneration, если их всего только два.

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

Гм, а как это доказывает то, что освобождение ресурсов == уничтожение объекта.

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

ВВ>Ага. А зачем тогда GC.MaxGeneration, если их всего только два.
Для будующих версий сейчас это значение на любом FrameWork == 2...

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

ВВ>Гм, а как это доказывает то, что освобождение ресурсов == уничтожение объекта.
Это доказывает, что не только анменеджет ресурсы нужно уничтожать...

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

H_D>Здравствуйте, Воронков Василий, Вы писали:

ВВ>>Ага. А зачем тогда GC.MaxGeneration, если их всего только два.
H_D>Для будующих версий сейчас это значение на любом FrameWork == 2...

Гм, откуда дровишки? Стандартный референс ничего такого не содержит (не видел по крайней мере). Рихтер расписывает сборку мусора в дотнете с учетом большого кол-ва поколений.

ВВ>>Гм, а как это доказывает то, что освобождение ресурсов == уничтожение объекта.
H_D>Это доказывает, что не только анменеджет ресурсы нужно уничтожать...

Брр, речь о том, что освобождение ресурсов != уничтожение объекта. К тому же, когда ты открываешь файл, то и получаешь unmanaged-ресурс в общем-то. В любом случае непонятно, почему ты возражаешь против утверждения, что в дотнете нет детерминированного уничтожения объектов.