|
|
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
Хорошо, Framework.NET - по сути закрытый мирок. Весь код удовлетворяет некому соглашению, продуманному в глубине Майкрософта. И поэтому, сбор мусора - вполне выполнимая задача. Например, потому, что выделение памяти в обязательном порядке регистрируется в каком то центральном диспетчере во время выполнения программы. То же касается и интерпретируемых языков вообще. А если, допустим мне нужно добавить в мою библиотеку внешний компонент, а выполнение производится внутри среды, которая задумана со сборщиком мусора. А компонент - он об этом не знает и выделяет сам себе память как захочется (malloc) и возможно не чистит её или завершение этого кода происходит с ошибкой, а выделенная память остается навечно выделенной пока не завершится вся программа. Как можно было бы побороться с утечками памяти в арзитектуре с подключаемыми бинарными компонентами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2008, 14:54 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
FarusХорошо, Framework.NET - по сути закрытый мирок. Весь код удовлетворяет некому соглашению, продуманному в глубине Майкрософта. И поэтому, сбор мусора - вполне выполнимая задача. Например, потому, что выделение памяти в обязательном порядке регистрируется в каком то центральном диспетчере во время выполнения программы. То же касается и интерпретируемых языков вообще. А если, допустим мне нужно добавить в мою библиотеку внешний компонент, а выполнение производится внутри среды, которая задумана со сборщиком мусора. А компонент - он об этом не знает и выделяет сам себе память как захочется (malloc) и возможно не чистит её или завершение этого кода происходит с ошибкой, а выделенная память остается навечно выделенной пока не завершится вся программа. Как можно было бы побороться с утечками памяти в арзитектуре с подключаемыми бинарными компонентами? либо компонент managed - от дотнета или подобных виртуальных машин, либо сам занимается сбором мусора. managed компонент тупо не может быть запушен без этой самой виртуальной рабочей машины ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2008, 15:35 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
Сборщики мусора есть и на C++ (boehm) Погугли также memory leak detectors ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2008, 16:00 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
FarusА если, допустим мне нужно добавить в мою библиотеку внешний компонент, а выполнение производится внутри среды, которая задумана со сборщиком мусора. Всё зависит от реализации. Если ты предусмотрел освобождение памяти во внешнем компоненте - то вызывай его явно через деструктор .Net Framework. Это гарантия что память (когда-нибудь) освободится. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.04.2008, 16:15 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
FarusА компонент - он об этом не знает и выделяет сам себе память как захочется (malloc) и возможно не чистит её или завершение этого кода происходит с ошибкой, а выделенная память остается навечно выделенной пока не завершится вся программа. Как можно было бы побороться с утечками памяти в арзитектуре с подключаемыми бинарными компонентами? Первая заповедь - не брать себе в приложение всякое дерьмо во-первых и без исходников во-вторых. Дерьмо - это потому как "возможно не чистит ее или происходит с ошибкой". Подчеркну: для решения "не брать" достаточно выполнения одного из этих условий. Сугубо теоретически бывает, что таки нужно использовать некую уникальную хрень, доступную сугубо в бинарниках, да еще и с недоступным разработчиком. Бывает... я бы сказал, раз в сто-двести человеко-лет :) Тогда начинаются разнообразные пляски с бубном. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.04.2008, 21:59 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
дерьмо с утечками пямяти - запускать в отдельном процессе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 00:42 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
softwarerБывает... я бы сказал, раз в сто-двести человеко-лет :) Тогда начинаются разнообразные пляски с бубном. По моему опыту, OCCI бывает несколько чаще ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 08:45 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)По моему опыту, OCCI Это средняя оценка, учитывающая в том числе опыт тех, кому такое вообще никогда не требовалось. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 09:18 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
softwarer Gluk (Kazan)По моему опыту, OCCI Это средняя оценка, учитывающая в том числе опыт тех, кому такое вообще никогда не требовалось. Спасибо, мне сразу стало легче ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 09:39 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
Gluk (Kazan)Спасибо, мне сразу стало легче (Пожимая плечами) Да не за что. Я не совсем понимаю, нафига вам сидеть голым задом на ежике, но наверное для чего-то полезно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 09:51 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
softwarer Gluk (Kazan)Спасибо, мне сразу стало легче (Пожимая плечами) Да не за что. Я не совсем понимаю, нафига вам сидеть голым задом на ежике, но наверное для чего-то полезно... К сожалению, эта тема не для форума. Вот за рюмкой чая, я бы охотно обсудил некоторые перепитии расейскава IT-буизнесу млять ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 09:59 |
|
||
|
Опять видимо бредовый вопрос
|
|||
|---|---|---|---|
|
#18+
Изопропилдерьмо с утечками пямяти - запускать в отдельном процессе Тогда после убийства процесса утёкшая память же освободится? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.04.2008, 15:20 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=35282791&tid=1345327]: |
0ms |
get settings: |
10ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
185ms |
get topic data: |
8ms |
get forum data: |
3ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 237ms |
| total: | 518ms |

| 0 / 0 |
