Re[18]: Смотрел на Java код. ...много думал.
От: Павел Кузнецов  
Дата: 11.11.05 00:33
Оценка:
VladD2,

>>> ты мне покажи засилие вопросв типа "у меня течет ххх... ничего не помогает... как быть?"

>
> ПК>Ты вопросы читал?
>
> Я его писал.

Последний шанс. Вопросы те, ссылки на которые я привел выше.

> ни в какое сравнение с постоянным отслеживанием политик владения объектами не идет.


Проблема как раз в том, что, как видно по вопросам, ссылки на которые я привел выше, это все равно приходится делать, только в условиях когда об этом постоянно не заботятся (читай, когда с этим делом бардак, и (почти) нет средств автоматизации этих задач).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Re: Смотрел на Java код. ...много думал.
От: _Winnie Россия C++.freerun
Дата: 11.11.05 06:35
Оценка:
Здравствуйте, c-smile, Вы писали:

CS>Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!

CS>результат который вот реально получился тот же примерно что и поймать GPF в С++.
CS>Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько
CS>бы вызвало устранение GPF.

Гы. Если писать на правильном С++ и если где-то есть catch (std::bad_alloc &) или catch (...) при обработке запроса, результат будет примерно такой же
Правильно работающая программа — просто частный случай Undefined Behavior http://rsdn.org/File/23256/catsmiley.gif
Re[19]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 11.11.05 16:14
Оценка:
Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Последний шанс.




ПК> Вопросы те, ссылки на которые я привел выше.


Читал. И про наличие утечек там ни слова. Там один теоритеческие вопросы.

>> ни в какое сравнение с постоянным отслеживанием политик владения объектами не идет.


ПК>Проблема как раз в том, что, как видно по вопросам, ссылки на которые я привел выше, это все равно приходится делать, только в условиях когда об этом постоянно не заботятся (читай, когда с этим делом бардак, и (почти) нет средств автоматизации этих задач).


Это твои выдумки. Никто о политиках владения в большинстве случаев не заботится. Все получается само собой. Ты просто проектируешь граф объектов и пишеш код его использующий. Ни в какое сравнение с отслеживанием политик владения в С++ (коих море) это не идет. Пытаться поставить тут знак равенства значит заниматься банальным обманом.
... << RSDN@Home 1.2.0 alpha rev. 618>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[5]: Ответ всем сразу.
От: kliff Россия http://www.esignal.ru
Дата: 16.11.05 07:37
Оценка:
Здравствуйте, Nickolay Ch, Вы писали:

CS>>Извиняюсь но как минимум код должен разрабатываться с применением инженерной совести.

CS>>А специфика задачи...

NC>Ну вот опять совесть полезла. Что такое совестьЮ тогда давайте пофлеймим, только уж лучше в Священных войнах.

NC>Писать надо так, как целесообразней, сиречь, так, что быстрее привелет нас к результатую. Целесообразность целиком зависит от задачи.

Целесообразность ни при чем. Только на самом верхнем уровне можно писать абы как. Все что находится под ним — вылизывается сообразно глубине.
Re[10]: Смотрел на Java код. ...много думал.
От: astranom  
Дата: 17.11.05 13:02
Оценка: :)
CC>>AFAIK убиение ненужного происходит не сразу после pointer = NULL; а тогда, когда сработает некая логика в GC...

VD>Убиения не просходит вообще RTFM (извинясь за грубость).

VD>Логика ЖЦ ищет живые объекты, а не мертвые.

Я пока работал в основном С++. Можете пояснить работу GC.
Судя по описанию работы ЖЦ мне кажется, что он может затруднять поиск ошибок.
Если в С++ я уничтожил объект, то при при попытке обратиться к ниму снова (на самом деле мне нужен другой объект, но я забыл изменить указатель) я получаю ошибку.
При использовании ЖЦ, как такую ошибку найти? Ведь объект не уничтажается, если есть ссылки на него (ошибочные).
Re[11]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.05 13:49
Оценка:
Здравствуйте, astranom, Вы писали:

A>Я пока работал в основном С++.


В этом все и дело. Ты живешь в своем мире предрассудков. Поверь, что есть другие миры где проблем С++ просто не существует.

A>Можете пояснить работу GC.


Например:
Вопросы по GC
Автор: Anton Batenev
Дата: 17.11.05

и вообще поиск по этому форуму и форума по дотнету очень помогает.

A>Судя по описанию работы ЖЦ мне кажется, что он может затруднять поиск ошибок.

A>Если в С++ я уничтожил объект, то при при попытке обратиться к ниму снова (на самом деле мне нужен другой объект, но я забыл изменить указатель) я получаю ошибку.
A>При использовании ЖЦ, как такую ошибку найти? Ведь объект не уничтажается, если есть ссылки на него (ошибочные).

Эта ошибка не связана с ЖЦ. Эта ошибка связана с тем, что ты используешь не типобезопасный язык программирования и соотвественно не типобезопасный код. В типобезопасном языке подобную ошибку просто невозможно соврешить.

ЖЦ как раз помогает избавиться от таких ошибо. Тебе просто не нужно уничтожать объекты. Ты просто держишь ссылку на объект или забывашь об объекте теряя ссылку. Так что ситуации когда у тебя есть указатель, но он указывает в никуда просто не существует. Языки типа C#, т.е. типобезопасные языки, в безопасном режиме просто не позволяют штатными средствами получить некорректный укзатель.

Собственно в С++ есть следующие способы получить некорректный указатель:
1. Освободить память и использовать указатель который ранее указывал на эту память.
2. Вручную задать неверное значение указателю. Например, в следствии реинтерпретации памяти в погоне за повышением быстродействия.
3. Произвести некорректную арифметическую операцию с указателем. Это можно сделать как напрямую, так и просто ошибившись с индексом массива.

В безопасном режиме C# без применения интеропа такие ошибки невозможны в принципе. Язык и рантайм котролируют все подобные ситуации или вовсе берут их на себя предоставляя в замен более высокоуровневые конструкции.

С++ тоже позволяет уменьшить риски связанные с описанными случаями, но это требует значительного и постоянного напряжения усилий программиста, что особенно в больших коллективах, приводит к снижению скорости разработки и неизбежно ведет к ошибкам. Для уменьшения ошибок связанных с ошибками типизации используются так называемые политики владения. В реальных проектах почти всегда не удается программировать исключительно в рамках выбранных политик владения, так как периодически приходится обращаться к С-АПИ (например, ВыньАПИ) и т.п. К тому же использование разных библиотек приводит к тому, что в одном проекте появляются сразу несколько разных политик владения. Ну, и вообще отслеживание соотвествия политике владения является не простой задачей.

Поиск ошибок связанных с типизацией очень сложен. Отчасти его облегчают средства вроде рантайм-проверок вставляемых компилторами и программ вроде Баундчерека. Но все равно это куда сложнее чем просто не иметь подобных ошибок.

С другой стороны программисту привкшему к тому, что типизацию можно легко обойти порой бывает очень трудно понять и темболее привыкнуть к средам в которых контроль типизации стопроцентный. Хорошм примером тому является наш уважаемый Пвел Дворкин.
... << RSDN@Home 1.2.0 alpha rev. 618>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[12]: Смотрел на Java код. ...много думал.
От: Kluev  
Дата: 17.11.05 14:13
Оценка: :)
Здравствуйте, VladD2, Вы писали:

VD>ЖЦ как раз помогает избавиться от таких ошибо. Тебе просто не нужно уничтожать объекты. Ты просто держишь ссылку на объект или забывашь об объекте теряя ссылку. Так что ситуации когда у тебя есть указатель, но он указывает в никуда просто не существует. Языки типа C#, т.е. типобезопасные языки, в безопасном режиме просто не позволяют штатными средствами получить некорректный укзатель.


А вот это как раз полная ж-па. К примеру когда у меня есть сеть и я хочу выкинуть один узел чтобы ее перестроить, то я удаляю его (физически) и перестраиваю сеть, если я ошибся в алгоритме и в элементах остались указатели на этот мертвый узел, то ошибка сразу вылезет . Когда есть GC то мертвые души будут вести себя как живые, и в отладке будет гемор. Можно конечно завести в обьект поле is_dead, но тогда фактически в каждую функцию прийдется ставить проверку if ( is_dead ) {...}, но это имхо попахивает гемором.

VD>Собственно в С++ есть следующие способы получить некорректный указатель:

VD>1. Освободить память и использовать указатель который ранее указывал на эту память.
Такая ошибка быстро отлавливается и локализуется, что есть благо. Мертвые души мне в программе не нужны.

VD>2. Вручную задать неверное значение указателю. Например, в следствии реинтерпретации памяти в погоне за повышением быстродействия.

Это очень редкая ситуация, да и ловится легко.

VD>3. Произвести некорректную арифметическую операцию с указателем. Это можно сделать как напрямую, так и просто ошибившись с индексом массива.

В этом случае если буде неккоректный указатель-то это благо. Легко выловишь, гораздо хуже кода ошибся с индексом и вернул корректный (физически), но некорректный алгоритмически указатель.

VD>В безопасном режиме C# без применения интеропа такие ошибки невозможны в принципе. Язык и рантайм котролируют все подобные ситуации или вовсе берут их на себя предоставляя в замен более высокоуровневые конструкции.

Только от алгоритмических это не спасет.

VD>С++ тоже позволяет уменьшить риски связанные с описанными случаями, но это требует значительного и постоянного напряжения усилий программиста

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


VD>Поиск ошибок связанных с типизацией очень сложен. Отчасти его облегчают средства вроде рантайм-проверок вставляемых компилторами и программ вроде Баундчерека. Но все равно это куда сложнее чем просто не иметь подобных ошибок.

Я полным ходом юзаю множественное наследование в С++, никогда не было ошибок связанных с типизацией. Да и откуда им взятся? Юзаем dynamic_cast, а небезопастные привдения используются осознанно да и то в классах хелперах

VD>С другой стороны программисту привкшему к тому, что типизацию можно легко обойти порой бывает очень трудно понять и темболее привыкнуть к средам в которых контроль типизации стопроцентный. Хорошм примером тому является наш уважаемый Пвел Дворкин.

100% контроль так же означает и 100% ограничение. А иногда требуется хак, никуда не денешься.
Re[12]: Смотрел на Java код. ...много думал.
От: astranom  
Дата: 17.11.05 15:32
Оценка: +1
Посмотрел статьи, но так до конца и не понял. Можете прояснить ситуацию, мне это важно — рассматриваю возможность пересеть на Java.

VD>ЖЦ как раз помогает избавиться от таких ошибо. Тебе просто не нужно уничтожать объекты. Ты просто держишь ссылку на объект или забывашь об объекте теряя ссылку.


VD> Языки типа C#, т.е. типобезопасные языки, в безопасном режиме просто не позволяют штатными средствами получить некорректный укзатель.


Это-то и беспокоит. Если в с++, есть 2-указателя на один объект. Мне надо освободить память и изменить оба указателя. Я забыл изменить один из них, при первом запуске я получаю ошибку -> нахожу -> исправляю
Как это будет работать в С#? Подозреваю, что если я изменю только один указатель, а второй будет указывать на не нужный объект — то GC не удалит его. Программа работать будет — но неправильно. И иди ищи где ты ошибся.
Re[13]: Смотрел на Java код. ...много думал.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.11.05 15:59
Оценка:
Здравствуйте, astranom, Вы писали:

A>Это-то и беспокоит. Если в с++, есть 2-указателя на один объект. Мне надо освободить память и изменить оба указателя. Я забыл изменить один из них, при первом запуске я получаю ошибку -> нахожу -> исправляю


Это-то так. Плохо только, что это не обязательно произойдет сразу в момент обращения ко второму указателю. Если бы сразу, то на С++ было бы куда приятнее программировать.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re: Смотрел на Java код. ...много думал.
От: n0name2  
Дата: 17.11.05 16:16
Оценка:
Здравствуйте, c-smile, Вы писали:

не все так плохо как вы думаете...

CS> // Пеночка №1: чтобы сделать нечто полезное с текстовыми (ASCII)

CS> // данными их надо в строку widechar загнать.
CS> // Не барское это дело с bytes работать.
CS> // Реаллокация буфера №1 — кол-во байт +2N.
CS> String header_line = new String( line.get() );

реально это делается только для строк в хэдере, соот-но само тело файла тут обрабатыватся не будет.

новый объект в яве занимает всего несколько байт и выделение их в отличае от malloc() происходит не поиском свободного фрагмента памяти а простой инкрементацией поинтера. если правильно помню то на intel процессрах гарантируется что аллокация занимает не более 8 инструкций процессора против более 50 у malloc()

собственно, релокации не будет т.к. ява переиспользует байтовый массив при аллокации новой строки при условии что размер тотже. собственно, код библиотеки можно слегка подхачить чтобы переиспользовать байтовый массив при substring().

    public String(String original) {
    int size = original.count;
    char[] originalValue = original.value;
    char[] v;
      if (originalValue.length > size) {
        v = new char[size];
         System.arraycopy(originalValue, original.offset, v, 0, size);
     } else {
        v = originalValue;
     }
    this.offset = 0;
    this.count = size;
    this.value = v;
    }



CS> // Пеночка №2: делаем еще одну строку потому как нам надо

CS> // регистронезависимый парсинг делать.
CS> // Реаллокация буфера №2 — кол-во байт +2N+2N.
CS> header_line = header_line.toUpperCase().substring( 0, len — 2 );

реаллокация конечно будет, но, все старые объекты тутже уберутся GC, так что памяти съедать не будут. кстати, деаллокация в жабе тоже практически бесплатная в отличае от C/C++.

CS> // Щаз будем парсить.

CS> // Аллокация объекта — сколько ест — то нам не ведомо.
CS> StringTokenizer v = new StringTokenizer(header_line, ": ");

всего-то несколько байт на запрос, короче несерьезно.

CS> // Теперича значить толкаем на стек try frame

CS> // потому как нужно ловить NumberFormatException в Integer.parseInt
CS> try{
CS> v.nextToken();
CS> v.nextToken(" ");
CS> ContentLen = Integer.parseInt( v.nextToken() );
CS> }catch(Exception e3){}
CS> }

точно не помню, но, где-то читал что в яве эксепшены приводят к оверхеду только если они были реально брошены. но можно просто отлов вынести повыше — так обычно и делают на самом деле.

CS>Итого загрузка 1мб файла вызывает аллокацию 5мб памяти. Вот серверок-то и дохнет....

CS>100 тредов и "шоб ви жили на один page file"

это только проблемы MS Java (которой не обновлялась годами, и которую нормальные люди давно не используют) и того что нет thread pool. те 5мб скорее всего отъедены "про запас" чтобы лишних malloc() не делать, да и все это подберется GC моментально, причем не останавливая другие потоки.

попробуйте на последнюю версию Java5 все перевести — должно быть much better.

CS>Резюме: Наличие высокоуровневых языков с GC и библиотек это конечно здорово, но!

CS>результат который вот реально получился тот же примерно что и поймать GPF в С++.
CS>Для нахождения где оно и как оно клинит сервер ушел один день — ровно столько сколько
CS>бы вызвало устранение GPF.

хотите сказать что после того как вы переписали все это на использование байтовых массивов стало намного лучше? неверю, хотя на MS Java все может быть. лучше бы thread pool сделали, на Java5 перешли и решили не только эту проблему а сразу много всего.

а вообще — я бы конечно написал это несколько подругому — использовал бы NIO и regexpы. или вообще не парился а взял бы одну из десятка реализаций lightweight http.

и вообще про память — на нормальном серваке должно стоять 32гб памяти минимум. стоит это достаточно дешево (на порядок дешевле чем труд програмеров по оптимизации каждого байта). и спокойно будут 1000 потоков с 5мб хипом у каждого жить.
Re[13]: Смотрел на Java код. ...много думал.
От: GlebZ Россия  
Дата: 17.11.05 16:31
Оценка:
Здравствуйте, Kluev, Вы писали:

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

Откуда сведения? Почему не знал?
K> Когда есть GC то мертвые души будут вести себя как живые, и в отладке будет гемор. Можно конечно завести в обьект поле is_dead, но тогда фактически в каждую функцию прийдется ставить проверку if ( is_dead ) {...}, но это имхо попахивает гемором.
Отвечу на вопрос: можно ли организовать утечку в памяти с Net GC. Отвечаю, можно. Но только организовать.
Ты сразу дай знать что тебе нужно. Если тебе нужно удалить объект, то удаляй все ссылки. В случае невыполнения, в чистом С++, ты будешь общаться с памятью как с живым объектом с неопределенным результатом. В Net ты будешь общаться с живым объектом потому что он живой.
Если же ты хочешь пометить объект как удаленный, то помечай как удаленный. Ты как то непонятно перенес проблему предметную на технологический уровень.

VD>>Собственно в С++ есть следующие способы получить некорректный указатель:

VD>>1. Освободить память и использовать указатель который ранее указывал на эту память.
K>Такая ошибка быстро отлавливается и локализуется, что есть благо. Мертвые души мне в программе не нужны.
Предотвращается, да. А вот ловится — нет. Иногда и профайлер не помогает. Он сам по себе падает от таких программ.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[13]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.05 16:53
Оценка: :)
Здравствуйте, astranom, Вы писали:

A>Это-то и беспокоит. Если в с++, есть 2-указателя на один объект. Мне надо освободить память и изменить оба указателя. Я забыл изменить один из них, при первом запуске я получаю ошибку -> нахожу -> исправляю


Попробуй перестать думать о том, что тебе нужно освободить память. Ты же не думашь о том, что тебе нужно дышать? Вот и тут не нужно думать об управлении памятью.

Если у тебя есть двае ссылки на один объект, то и оперируй ими. А память не освобождай.

Не нужно вообще думать блоками памяти. Нужно думать програмными сущьностями. Нужна ссылка — значит она указывает ну нужный объект. Не нужна — значит она должна содержать null.

A>Как это будет работать в С#? Подозреваю, что если я изменю только один указатель, а второй будет указывать на не нужный объект — то GC не удалит его. Программа работать будет — но неправильно. И иди ищи где ты ошибся.


Если ты имешь две постоянные ссылки на один объект (что уже навиват на раздумья) и забыл поправить одну из них, то ты получишь логическую ошибку которая приведет к неверному поведению программы. Найти ошибку можно будет банальным отладчиком. При подобной ошибке в С++ у тебя будет так называемое неопределенное поведение. Это значит, что будет просто принципиально невозможно предсказать, как поведет себя система. Возможно ты получишь вылет. Возможно ты запортишь память отведенную другому объекту. Возможно все вообще будет работать как надо до определенного времени. Причем с большой долей веорятности эта ошибка приведет к тому, что реальная ошибка будет проявляться совершенно в другом месте. И скорее всего совершенно непонятным образом. Такие ошибки даже при наличии специальных средств искать очень не просто. Они зачастую порождают ошибки вторго и третьего порядка (когда некоторое действи не приводит сразу к вылету, а только портит память в днругом месте, а вылет случается в совершенно не предсказуемом месте.

ЗЫ

Мужики, поймите (и не обижайтесь). Вы живете в своем мире. Ваш мозг думает только одним единственным образом. Я уже который раз пытаюсь объяснить вам казалось бы совсем примитивные вещи, но вы просто не можете переключиться со своей точки зрения.

Очень советую вам познакомиться с языками и средами в которых реализовано автоматическое управление памятью. Это, кстати, не только дотнет или Ява. Сюда отноятся почти все скриптовые языки (напрмер Руби и Питон). Уверяю вас, что как только вы познакомитесь с ними по ближе все ваши вопросы отпадут сами собой.

Вы даже не представляете насколько проще становится отладка когда из списка возможных ошибок исключаются ошибки связанные с типами.
... << RSDN@Home 1.2.0 alpha rev. 618>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Смотрел на Java код. ...много думал.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 17.11.05 16:58
Оценка: +1
Здравствуйте, VladD2, Вы писали:

VD>Очень советую вам познакомиться с языками и средами в которых реализовано автоматическое управление памятью. Это, кстати, не только дотнет или Ява. Сюда отноятся почти все скриптовые языки (напрмер Руби и Питон). Уверяю вас, что как только вы познакомитесь с ними по ближе все ваши вопросы отпадут сами собой.


VD>Вы даже не представляете насколько проще становится отладка когда из списка возможных ошибок исключаются ошибки связанные с типами.


Вот чесно тебе скажу Влад. Пользуюсь Ruby, нравится мне, что не нужно о памяти думать. Не нравится, что a = b на самом деле означает копирование ссылок, а не объектов. Это приводит к труднообнаруживаемым проблемам. А уж забыть какую-то ссылку в nil установить -- так это вообще раз плюнуть. И будет затем чего-нибудь где-нибудь болтаться. Хуже всего, если с неожиданными проявлениями (вроде как изменяем один объект, а изменения еще где-то оказываются, потому что ссылки-то на один объект).
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[2]: Смотрел на Java код. ...много думал.
От: vladserge Россия  
Дата: 17.11.05 17:20
Оценка:
Здравствуйте, n0name2, Вы писали:

N>новый объект в яве занимает всего несколько байт и выделение их в отличае от malloc() происходит не поиском свободного фрагмента памяти а простой инкрементацией поинтера. если правильно помню то на intel процессрах гарантируется что аллокация занимает не более 8 инструкций процессора против более 50 у malloc()


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


N>реаллокация конечно будет, но, все старые объекты тутже уберутся GC, так что памяти съедать не будут. кстати, деаллокация в жабе тоже практически бесплатная в отличае от C/C++.


N>точно не помню, но, где-то читал что в яве эксепшены приводят к оверхеду только если они были реально брошены. но можно просто отлов вынести повыше — так обычно и делают на самом деле.


N>это только проблемы MS Java (которой не обновлялась годами, и которую нормальные люди давно не используют) и того что нет thread pool. те 5мб скорее всего отъедены "про запас" чтобы лишних malloc() не делать, да и все это подберется GC моментально, причем не останавливая другие потоки.


N>попробуйте на последнюю версию Java5 все перевести — должно быть much better.


N>хотите сказать что после того как вы переписали все это на использование байтовых массивов стало намного лучше? неверю, хотя на MS Java все может быть. лучше бы thread pool сделали, на Java5 перешли и решили не только эту проблему а сразу много всего.


N>а вообще — я бы конечно написал это несколько подругому — использовал бы NIO и regexpы. или вообще не парился а взял бы одну из десятка реализаций lightweight http.


N>и вообще про память — на нормальном серваке должно стоять 32гб памяти минимум. стоит это достаточно дешево (на порядок дешевле чем труд програмеров по оптимизации каждого байта). и спокойно будут 1000 потоков с 5мб хипом у каждого жить.




не я угараю. я конечно понимаю, это ваше первое сообщение и все такое....
Вы б поискали по форуму про MS VM как она попрежнему всех делает... ох, ну ладно. и 32гб..
С Уважением Сергей Чикирев
Re[3]: Смотрел на Java код. ...много думал.
От: n0name2  
Дата: 17.11.05 17:53
Оценка:
Здравствуйте, vladserge, Вы писали:

V>Вы б поискали по форуму про MS VM как она попрежнему всех делает...


нюню... кого она делает? это вы про отрисовку строк чтоли? кроме как быстро рисовать MS VM ниче не может, вообще ничего. если надо че-то быстро отрисовывать на Java5 юзайте SWT и будет вам щастье.

в любом коректном микробенчмарке не юзающем GDI MS VM сольет по полной.

вообще судя по всему вы явой интересуетесь раз в полгода а не юзаете ее сервер сайдный вариант каждый день.
Re[15]: Смотрел на Java код. ...много думал.
От: VladD2 Российская Империя www.nemerle.org
Дата: 17.11.05 18:16
Оценка: +1
Здравствуйте, eao197, Вы писали:

E>Вот чесно тебе скажу Влад. Пользуюсь Ruby, нравится мне, что не нужно о памяти думать. Не нравится, что a = b на самом деле означает копирование ссылок, а не объектов. Это приводит к труднообнаруживаемым проблемам. А уж забыть какую-то ссылку в nil установить -- так это вообще раз плюнуть. И будет затем чего-нибудь где-нибудь болтаться. Хуже всего, если с неожиданными проявлениями (вроде как изменяем один объект, а изменения еще где-то оказываются, потому что ссылки-то на один объект).


Про Руби не скажу, а на C# мне практически не приходится вручную ссылки в null устанавливать. Как-то все и без того получается. К тому же Шарп позволяет довольно много всего. Так есть вэлью-типы которые копируются по содержимому, и есть возможность воспользоваться привдением типов с копированием.

В общем, проблем с копированием ссылок я как-то даже в самом начале не почувствовал.
... << RSDN@Home 1.2.0 alpha rev. 620>>
http://nemerle.org/Banners/?g=dark
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[14]: Смотрел на Java код. ...много думал.
От: Kluev  
Дата: 18.11.05 11:19
Оценка: 1 (1) -1
Здравствуйте, GlebZ, Вы писали:

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

GZ>Откуда сведения? Почему не знал?
K>> Когда есть GC то мертвые души будут вести себя как живые, и в отладке будет гемор. Можно конечно завести в обьект поле is_dead, но тогда фактически в каждую функцию прийдется ставить проверку if ( is_dead ) {...}, но это имхо попахивает гемором.
GZ>Отвечу на вопрос: можно ли организовать утечку в памяти с Net GC. Отвечаю, можно. Но только организовать.
GZ>Ты сразу дай знать что тебе нужно. Если тебе нужно удалить объект, то удаляй все ссылки. В случае невыполнения, в чистом С++, ты будешь общаться с памятью как с живым объектом с неопределенным результатом. В Net ты будешь общаться с живым объектом потому что он живой.
GZ>Если же ты хочешь пометить объект как удаленный, то помечай как удаленный. Ты как то непонятно перенес проблему предметную на технологический уровень.

Ты все не понял. Ситуация состоит в том, что в процессе программирования алгоритмических ошибок не избежать. К примеру я хочу удалить обьект, естественно я должен обнулить все ссылки на него. Если в результате алгоритмической ошибки программера обнулены не все ссылки то ситуация будет следущей:
В С++:
Я удалю обьект делитом (физически), а когда программа пойдет по невалидной ссылке то как правило будет runtime error. В деббагере это место сразу локализуется и дальше можно определить причину, почему осталась невалидная ссылка и исправить алгоритм.

В С# если я по ошибке не обнулю все ссылки, то заведется мертвая душа. Т.е. алгоритмически обьект должен быть мертвым, а физически он жив. При обращении по этим ссылкам рантайм error не возникнет и программа будет работать дальше только неправильно(алгоритмически). В результате ошибку будет не так то просто найти т.к. она может проявится только в выходных данных или еще бог знает на каком этапе работы. Тогда найти место откуда ноги ростут будет достаточно проблематично.
Re[15]: Смотрел на Java код. ...много думал.
От: GlebZ Россия  
Дата: 18.11.05 12:06
Оценка: 2 (1)
Здравствуйте, Kluev, Вы писали:

K>Ты все не понял. Ситуация состоит в том, что в процессе программирования алгоритмических ошибок не избежать.

Не избежать. Но их меньше чем элементарных ошибок, и они чаще сразу тестируются при разработке.
K>В С++:
K>Я удалю обьект делитом (физически), а когда программа пойдет по невалидной ссылке то как правило будет runtime error. В деббагере это место сразу локализуется и дальше можно определить причину, почему осталась невалидная ссылка и исправить алгоритм.
Как правило? О, нет. Это адская ошибка. Обычно она появляется не в лишней ссылке, а в лишнем(преждевременном) делете. Пока это пространство под убитым объектом никто не заполнил, ее можно считать живой и работающей и никто этого не замечает. Проявляется вообще сказочно. Может проявиться например, в Debug все работает, а под Release ни фига. Или еще хуже, все работает, дает полезный результат, но тут тронул пупок и вся задница отвалилась. Притом долго смотришь на код который только что правил. Начинаешь верить в потусторонние силы, и что у программы есть бог который тебя проклял. Теряешь веру в собственную логику. Рука тянется к бубну. Например, каким образом вставка тупого if может выдавать access violation. Мысль заглянуть в код, который уже два года нормально работает отгоняется как неправдоподобная. А вот когда уже взглянешь туда, тоже начинаешь удивляться. Каким образом такое, мало того что работало два года, но еще умудрялось возвращать правильные результаты. Система искуственного интелекта в действии. Вобщем, хуже такой ошибки быть ничего не может.

С уважением, Gleb.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Re[16]: Смотрел на Java код. ...много думал.
От: eao197 Беларусь http://eao197.blogspot.com
Дата: 18.11.05 12:26
Оценка:
Здравствуйте, GlebZ, Вы писали:

GZ>хуже такой ошибки быть ничего не может.


Все этот так (Re[13]: Смотрел на Java код. ...много думал.
Автор: eao197
Дата: 17.11.05
).
Но только, если ошибка есть, то она обязательно проявится. А вот со сборщиком мусора -- может вообще не проявиться.
... << RSDN@Home 1.1.4 stable rev. 510>>


SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[17]: Смотрел на Java код. ...много думал.
От: n0name2  
Дата: 18.11.05 12:38
Оценка:
Здравствуйте, eao197, Вы писали:

E>Все этот так (Re[13]: Смотрел на Java код. ...много думал.
Автор: eao197
Дата: 17.11.05
).

E>Но только, если ошибка есть, то она обязательно проявится. А вот со сборщиком мусора -- может вообще не проявиться.

если никак не проявляется, значит ее нет вообще. если вдруг память стала отъедатся и не возвращатся то если большое кол-во инструментов анализирующих heap, дающих stack trace того места где была аллокация и т.д. но это бывает достаточно редко и никакой мистики вроде неопределенного поведения не вызывает.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.