macro и micro memory management. Java и С - Философия программирования

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

VD>Пул на то и нужен, чтобы время выделения ресурса стремилось к нулю.

и он это делает при условии своевременного возврата ресурсов. если возврат ресурсов чуть задержать то пулу придется все время рости и толку от него не будет никакого.

VD>Вот и в дотнете для соеденений он используется именно для этого. Лично я выделяю соеденения примерно так:
VD>

VD>using (SqlConnection connection = new SqlConnection(connectionString))
VD>{
VD>    // выполение запросов...
VD>}
VD>

кстати, на Жабе я это делаю примерно так

int count = pool.query("select count(*) from abc where a = ?", 123, new ScalarHandler<Integer>());

а все незаслуженно нелюбимые дотнетчиками try/finally внутри спрятаны.

VD>Но даже если этого не сделать, а просто забывать ссылки, то при нехватке соеденений будет собран мусор и они все снова вернутся в пул соеденений.

когда будет возвращен? через минуту, день, месяц? это слишком (фатально) поздно если у тебя 100 запросов/сек. если он попал в перманент дженерэйшн а свободной памяти полно то в обозримом будующем можно на это не расчитывать.

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

VD>Ведь тут кроме модификации языка нужно еще приучать к этому делу отладчик, редактор, средства рефакторинга и т.п.

как раз это небольшая проблема. такого рода плагины к Eclipse/IDEA пишутся пачками.

VD>Однако пока что ее нет и лично ты долбишь try/finally своими ручками. И это не единственный паттернк который тебе придется долбить самому. Мни лично это делать не охота. Лучше уж иметь их встроенными в язык. Поэтому я предпочитаю Шарп.

ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>".

во-вторых, ты долбишь (ну хорошо — VS долбит)

namespace {
}

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

int count = pool.query("select count(*) from a", new ScalarHandler<Integer>());

в-четвертых ИМХО рассматривать "синтаксический оверхед" (весьма субъективный) как более-менее значительный критерий выбора платформы просто несерьезно.

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

предположим что есть плагины к очень популярной IDE которые расширяют отладчик и т.п. для работы с Syntax Extender, и что — перейдешь на Жабу? (ради такого не лень будет потратить пару — тройку дней)

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

VD>>>Это если где-нить внизу не попадется неуправляемый стековый фрэйм.

ANS>>Хм. Интересный вопрос. Ситуация маловероятная, но всё же... Нужно уточнить.

VD>Что же это маловерятная? Пока ОС неуправляемая, ситуация эта очень даже возможна.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>Карандаш картинкой? Это явный гон. Никто такого не умеет делать, только я умею, да и то со значительными ограничениями.

public partial class Form1 : Form
{
        protected override void OnPaint(PaintEventArgs e)
        {
                base.OnPaint(e);
                e.Graphics.DrawEllipse(
                        new Pen(new TextureBrush(Properties.Resources.Image1), 10),
                        10, 10, 100, 200);
        }
}

Еще вопросы?

MS> Нарисовать линию паттерном в виде произвольного битмапа, да еще и с фильтрацией — это не просто задача, это — мегазадача. Изобретение карандашей по сравнению с такой задачей — это детская песочница, не стоящая упоминания.

Незнаю как там с фильтрацией, а в GDI+ ресует.

MS>Тебя обманули, ООП заключается вовсе не в этом. Не спрашивай меня, в чем оно заключается, но могу сказать, что точно не в иерархиях классов.

Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

VD>public partial class Form1 : Form
VD>{
VD>        protected override void OnPaint(PaintEventArgs e)
VD>        {
VD>                base.OnPaint(e);
VD>                e.Graphics.DrawEllipse(
VD>                        new Pen(new TextureBrush(Properties.Resources.Image1), 10),
VD>                        10, 10, 100, 200);
VD>        }
VD>}
VD>

Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".

Ты, Влад, похоже вообще не понимаешь о чем речь. Поясняю еще раз. Этот "битмаповый карандаш" — это как раз тот самый объектно-ориентированный фуфел, который нафиг никому не нужен в реальности — это чисто обманка. В всяком случае, я не видел ни одного человека, которому хоть раз бы понабодилось нарисовать произвольную линию таким образом.
Нужно вот что:

http://antigrain.com/demo/line_patterns.zip

А теперь сопоставь результат с фалами 1...9.bmp
Во это то, что реально нужно и то, что микрософту слабо.

VD>Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.

Дизайн моей библиотеки выполнен в соответствии с классическими объектно-ориентированными канонами. И тем не менее, никаких иерархий классов там нет. Не нужны они.

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

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

VD>>Ведь тут кроме модификации языка нужно еще приучать к этому делу отладчик, редактор, средства рефакторинга и т.п.

N>как раз это небольшая проблема. такого рода плагины к Eclipse/IDEA пишутся пачками.

Пачками говоришь? А можно вот поглядеть не не пачку, а на один плагин поддерживающий этот самый The Java Syntactic Extender. А то языком то конечно пачками, но я то прекрасно понимаю сложность данной задачи и мне не верится, что можно вот так просто решать такие сложные задачи.

N>ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>".

Доблить это образно. Все же код пишется куда реже чем читается. Так что кроме скорости ввода нужно еще и на прототу восприятия внимание обращать.

N>во-вторых, ты долбишь (ну хорошо — VS долбит)

N>

N>namespace {
N>}
N>

N>ручками в каждом!

Я ни разу не написал ни одного пространства имен вручную. Оно уже есть. Я только меняю имена на подходящие. К тому же это уже минимальная конструкция и встречается она один раз на класс/файл. А вот try/finally-ов может быть куда больше и это далеко не минимальная конструкция. Это паттерн который каждый раз нужно реализовывать вручную, а потом мысленно разбирать его в коде. Точно так же, кстати, было с foreach до недавнего времени. И ничего хорошего в этом нет. Согласен, что решение на базе чего-то вроде Syntactic Extender было бы идеальным. Но, как я уже говорил, его нужно довести до промышленного качества. Расширения должны автоматом поддерживаться рефакторингом, отладчиком и т.п.

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

Да не чаще он используется. И как ты правильно заметил от него никуда не деться. Да и уменьшить его уже не удастся без потери информации. А вот заменить try/finally using-ом можно легко. Причем это только увеличит объем информации (паттерн будет виден без мысленного распознования). Да и ошибиться будет куда сложнее.

N>

N>int count = pool.query("select count(*) from a", new ScalarHandler<Integer>());
N>

Это частный случай. От использования и управления ресурсами все равно никуда не деться.

N>в-четвертых ИМХО рассматривать "синтаксический оверхед" (весьма субъективный) как более-менее значительный критерий выбора платформы просто несерьезно.

Вообще-то мы говорим о языке. Ну, да если говорить о платформе, то лично мне в Яве не нравится в первую очередь не JVM, а именно язык. Нельзя сказать, что в нем мне не нравится только синтаксический оверхэд, но и он влияет на отношение. В купе с некоторым количеством неустраненных граблей и неудобным интеропом он действительно отталкивает от языка, и как следствие от платформы.

Я бы вообще поставил вопрос по другому. Я вижу только два приемущества в Яве перед дотнетом. 1. Она перенесена на намного большее количество платформ. 2. Для нее есть больше фрэймворков и серверов в области разработки корпроративного ПО.

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

N>предположим что есть плагины к очень популярной IDE которые расширяют отладчик и т.п. для работы с Syntax Extender, и что — перейдешь на Жабу?

А почему бы и нет?

N>(ради такого не лень будет потратить пару — тройку дней)

Тройку дней на что? Ты серьезно считашь, что написать плагин к ИДЕЕ полностью интегрирующий Syntactic Extender — это занятие на тройку дней? Ну, ты крут!

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

N>и он это делает при условии своевременного возврата ресурсов. если возврат ресурсов чуть задержать то пулу придется все время рости и толку от него не будет никакого.

Так. Давай еще раз проанализируем ситуацию.

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

VD>>Вот и в дотнете для соеденений он используется именно для этого. Лично я выделяю соеденения примерно так:
VD>>

VD>>using (SqlConnection connection = new SqlConnection(connectionString))
VD>>{
VD>>    // выполение запросов...
VD>>}
VD>>

N>кстати, на Жабе я это делаю примерно так

N>

N>int count = pool.query("select count(*) from abc where a = ?", 123, new ScalarHandler<Integer>());
N>

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

N>а все незаслуженно нелюбимые дотнетчиками try/finally внутри спрятаны.

В частном случае. Да и то при реализации этого query все равно прийдется писать эти try/finally. Так зачем мучаться?

N>когда будет возвращен? через минуту, день, месяц?

См. выше.

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

MS>Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".

Ну, я надеялся, что ты справишся с нажатием на F5.

MS>Ты, Влад, похоже вообще не понимаешь о чем речь. Поясняю еще раз. Этот "битмаповый карандаш" — это как раз тот самый объектно-ориентированный фуфел, который нафиг никому не нужен в реальности — это чисто обманка. В всяком случае, я не видел ни одного человека, которому хоть раз бы понабодилось нарисовать произвольную линию таким образом.

Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.

MS>Нужно вот что:
MS>

Спору нет, это красиво. Спору нет, ты не зря ешь свой хлеб. Но и то что есть в GDI+ тоже востребовано и довольно круто по сравнению с GDI.

Собственно я тебе уже предлагал сделать альтернативу GDI+ на базе твоей либы. Но все это, согласись, немного из другой темы. Мы ведь говорим об ООП и выделении памяти. Не правда ли?

VD>>Сдается мне, что обманули тебя. Тебе подсунли процедурный стиль а-ля GDI. Мне он не нравится.

MS>Дизайн моей библиотеки выполнен в соответствии с классическими объектно-ориентированными канонами. И тем не менее, никаких иерархий классов там нет. Не нужны они.

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

... << RSDN@Home 1.2.0 alpha rev. 620>>

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

MS>>Для полной ясности, вообще-то, надо было привести еще и скриншот. Но мне удалось воспроизвести сей "шедевр".

VD>Ну, я надеялся, что ты справишся с нажатием на F5.

Твой код не компилируется. О, это была пестня. Сейчас насмешу. Ну запустил я студию (2003), создал новый C# Windows App. Дальше что? Копируем класс из твоего сообщения. Что за слово "partial"? Не знаем такого. Ладно, убираем. Но какую кнопку надо нажать, чтобы в Properties.Resources образовался Image1? Я такой не нашел. Но до этого дело даже не дошло — оно жалуется "System.Windows.Forms.Control.Properties is inaccessible due to its protection level". Это навеяло мне древнюю бодягу с MFC. Сначала там все данные и многие функции были private. Но с каждой новой версией все становилось все более и более public. И сейчас я тоже испытал мощное дежа-вю.
Но ладно, я решил, что можно и вручную загрузить. Смотрим класс Image и не находим у него ни конструктора с именем файла, ни метода Load. Ищем в интернете TextureBrush, находим, что надо использовать не Image, а Bitmap. Хорошо, пишем Bitmap bmp = new Bitmap("1.bmp"); и получаем облом — исключение. Оно не находит файла в каталоге проекта (какой там текущий каталог — я не знаю и как это выяснить — тоже не знаю). Поскольку нам надо только проверить, пишем абсолюный путь. И вот только теперь у нас все получилось.

Какая-то бесталанность во всем этом присутствует, вот за что я не люблю дот-нет — на выяснение самых элементарных вещей уходит уйма времени. А спросить стыдно — засмеют

VD>Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.

Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.

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

MS>Твой код не компилируется. О, это была пестня. Сейчас насмешу. Ну запустил я студию (2003), создал новый C# Windows App. Дальше что? Копируем класс из твоего сообщения. Что за слово "partial"? Не знаем такого.
ключевое слово: net 2.0. (Ты же не стал бы обижаться, если бы примеры из страуструпа отказались компилироваться на Classic С Compiler?).
MS>Ладно, убираем. Но какую кнопку надо нажать, чтобы в Properties.Resources образовался Image1? Я такой не нашел. Но до этого дело даже не дошло — оно жалуется "System.Windows.Forms.Control.Properties is inaccessible due to its protection level". Это навеяло мне древнюю бодягу с MFC. Сначала там все данные и многие функции были private. Но с каждой новой версией все становилось все более и более public. И сейчас я тоже испытал мощное дежа-вю.
MS>Но ладно, я решил, что можно и вручную загрузить. Смотрим класс Image и не находим у него ни конструктора с именем файла, ни метода Load.
Гм. А как же Image.FromFile()?
MS>Ищем в интернете TextureBrush, находим, что надо использовать не Image, а Bitmap. Хорошо, пишем Bitmap bmp = new Bitmap("1.bmp"); и получаем облом — исключение. Оно не находит файла в каталоге проекта (какой там текущий каталог — я не знаю и как это выяснить — тоже не знаю).
Гм. Боюсь тебя разочаровать, но эта проблема никакого отношения к дотнету не имеет. Это винда. Текущий каталог может показывать куда угодно. Я не очень понимаю, что именно ты имел в виду, когда указывал относительный путь. Тем более этого не понимает винда.
MS> Поскольку нам надо только проверить, пишем абсолюный путь. И вот только теперь у нас все получилось.
Все правильно. Если бы нам надо было реализовать какое-то другое поведение, то понадобилось бы сначала его продумать, а уже потом реализовывать.
Например, я бы этот битмэп вставил как Embedded Resource, и грузил через Image.FromStream(Assembly.GetManifestResourceStream()).
MS>Какая-то бесталанность во всем этом присутствует, вот за что я не люблю дот-нет — на выяснение самых элементарных вещей уходит уйма времени. А спросить стыдно — засмеют

И правильно, что стыдно. Потому что в дотнете как раз все очень логично и интуитивно понятно. Но эта интуиция забесплатно не дается. Хотя по сравнению с тем, сколько времени я убил на разбирательство с логикой #include при ознакомлении с С++, тонкости дотнета — это децкий лепед. Просто ты привык к определенным особенностям, и используешь их не задумываясь. Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.

VD>>Понимаеш ли. Я говорил о том о чем говорил. Тут кто-то начал с очень пафосным видом рассказывать о том что я "гоню". Этот код как бы объясняет этому кому-то о том, что он не прав.

MS>Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.
Опять ты смешиваешь архитектуру и реализацию. Вот не надо переносить косяки реализации на архитектуру. Да, парни, которые реализовывали это дело — халтурщики. И что теперь, выкидывать базовый класс из-за того, что есть убогие наследники?

1.1.4 stable rev. 510

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

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

ок, как часто происходит сборка нулевого поколения? сколько раз в секунду? предположим что есть пул со 50ю соединениями и есть нагрузка от 10 до 200 запросов/сек (совершенна типичная ситуация для задач которые обычно решаются на Жабе). вот у нас настал пик и мы потеряли за 0.25с все 50 соединений. неужели сборка 0го поколения происходит настолько часто (у меня в приложениях это бывает ну раз в минуту примерно)? и если да то какова вероятность попадения соединения в 1е/2е поколенье?

я правильно понял что ты предлагаешь в реализацию пула встраивать механизм который ЗНАЕТ о существовании ЖЦ? это же жуть какая-то! тут кода/оверхеда будет на порядок больше чем от какого-то там try/finally. ну предположим что он дернет ЖЦ — мол собирай. а можно сказать какое именно поколенье нужно собирать или это вызовет полную сборку мусора и остановку всего приложения более чем на секунду что совершенно неприемлемо (в любом уважающем себя Жабном приложении полная сборка не происходит никогда, разве что пару раз на стартапе).

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

а на этот случай есть вполне работоспособный PL/SQL (в отличае от мрачного T-SQL), причем на эту роскошь у заказчика часто деньги остаются — не надо платить МС за кучу лицензий.

кроме того, (хотя лично я и не люблю ОРМ) многие пользуются отличными продуктами для доступа к БД (Hibernate, JDO, EJB3, из которых для .НЕТ есть только альфа NHibernate) в виде объектов, там API уровнем намного выше.

VD>В частном случае. Да и то при реализации этого query все равно прийдется писать эти try/finally. Так зачем мучаться?

кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе.

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

N>>ну, во-первых try/finally ручками я не долблю а это далает IDEA, достаточно набрать "tf<Ctrl+J>".
VD>Доблить это образно. Все же код пишется куда реже чем читается. Так что кроме скорости ввода нужно еще и на прототу восприятия внимание обращать.

ну как сказать простота восприятия — у try/finally есть свои приемущества с т.з. чтения кода — видно какой именно метод вызывается при закрытии ресурса. и не надо помнить что это Disposable класс и т.д.

VD>Я ни разу не написал ни одного пространства имен вручную. Оно уже есть. Я только меняю имена на подходящие. К тому же это уже минимальная конструкция и встречается она один раз на класс/файл. А вот try/finally-ов может быть куда больше и это далеко не минимальная конструкция. Это паттерн который каждый раз нужно реализовывать вручную, а потом мысленно разбирать его в коде.

так я тоже не пишу try вручную

но у меня кол-во try/finally конструкций существенно меньше кол-ва файлов с исходным кодом. соот-но мустора от namespace больше чем от try/finally. и чтобы продратся через лишнюю пару curly braces от namespace у неподготовленного человека точно также уходят драгоценные секунды.

VD>Да не чаще он используется. И как ты правильно заметил от него никуда не деться. Да и уменьшить его уже не удастся без потери информации. А вот заменить try/finally using-ом можно легко. Причем это только увеличит объем информации (паттерн будет виден без мысленного распознования). Да и ошибиться будет куда сложнее.

не во всех случаях можно using приенять. сколько у тебя в проекте using и сколько namespace, посчитай если не лень? согласен с тем что ошибится сложнее с using, но это если редактировать код с помощью notepad, а там можно и закрывающюю скобку у namespace забыть. нормальный редактор тебе сразу покажет что ты забыл осводобить ресурс (ИДЕЯ знает типичные паттерны).

VD>Это частный случай. От использования и управления ресурсами все равно никуда не деться.

весь код и состоит из нескольких таких частных случаев. почти все они примерно в такие конструкции укладываются легко. в итоге получается намного более чистый код без пачки using или try/finally.

VD>Вообще-то мы говорим о языке. Ну, да если говорить о платформе, то лично мне в Яве не нравится в первую очередь не JVM, а именно язык. Нельзя сказать, что в нем мне не нравится только синтаксический оверхэд, но и он влияет на отношение. В купе с некоторым количеством неустраненных граблей и неудобным интеропом он действительно отталкивает от языка, и как следствие от платформы.

это субъективно. мне например в .НЕТ ненравятся namespaces, общепринятый стиль наименования (лень мне Shift все время жать) и мне кажется что делегаты совершенно не читаемы по сравнению с анонимными классами. кому-то наоборот эти вещи нравятся. но объективно на практике это ни на что не влияет. кстати, если вдруг будешь что-то на Жабе писать тебе с интеропом скорее всего не придется столкнутся ни разу. просто другой круг задач.

VD>Я бы вообще поставил вопрос по другому. Я вижу только два приемущества в Яве перед дотнетом. 1. Она перенесена на намного большее количество платформ. 2. Для нее есть больше фрэймворков и серверов в области разработки корпроративного ПО.

вот, это уже объективные факты. причем я бы добавил 3. бесплатна, думаю это скоро будет весьма актуально в свете борьбы с пиратстовом 4. огромный выбор различного готового софта на все случаи жизни и личто свой самый важный пунктик 5. совершенно другие задачи приходится решать Жаба программисту, как правило это сервер сайд с болшими нагрузками и распределенной средой, мне этот класс задач намного более интересен.

.НЕТ хорошо подходит для десктопных приложений под Винду. это его ниша и посягать на нее никто всерьез не пытается, хотя, OpenOffice вполне нормально работает и написан вообще на С++ в основном... еще я не понимаю почему таже ИДЕЯ (само существование которой ИМХО перевешивает все субъективные плюсы C#) написанная на Жабе небольшой питерской командой легко делает ВС над которым работает столько людей, причем на родном для МС поле — десктопные приложения.

VD>Тройку дней на что? Ты серьезно считашь, что написать плагин к ИДЕЕ полностью интегрирующий Syntactic Extender — это занятие на тройку дней? Ну, ты крут!

не полностью, конечно. думаю что за это время вполне можно взять ИДЕЙный плагин от какого-нибудь другого языка (GroovyJ например) и переделать его на поддержку большинства конструкций аналогичных C# — всяких там using и т.п.

кстати говоря, я бы был непротив отлаживать код полученный после применения Syntax Extender, по крайней мере можно breakpoint поставить на .close() а не не using.

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

N>ок, как часто происходит сборка нулевого поколения? сколько раз в секунду?
В зависимости от того как приложение работает с памятью. Может 100 раз в секунду, а может и раз в час.
N>предположим что есть пул со 50ю соединениями и есть нагрузка от 10 до 200 запросов/сек (совершенна типичная ситуация для задач которые обычно решаются на Жабе). вот у нас настал пик и мы потеряли за 0.25с все 50 соединений. неужели сборка 0го поколения происходит настолько часто (у меня в приложениях это бывает ну раз в минуту примерно)? и если да то какова вероятность попадения соединения в 1е/2е поколенье?
Нормальные люди используют using и соеденения возвращаются в пул сразуже после того как с ним поработали.
Просто Влад говорит о том что если гдето какойто разбдолбай забудет это сделать то ГЦ за ним приберет.

N>я правильно понял что ты предлагаешь в реализацию пула встраивать механизм который ЗНАЕТ о существовании ЖЦ?
А почему бы и нет?
N>это же жуть какая-то! тут кода/оверхеда будет на порядок больше чем от какого-то там try/finally. ну предположим что он дернет ЖЦ — мол собирай.
N>а можно сказать какое именно поколенье нужно собирать
Можно.
N>или это вызовет полную сборку мусора и остановку всего приложения более чем на секунду что совершенно неприемлемо (в любом уважающем себя Жабном приложении полная сборка не происходит никогда, разве что пару раз на стартапе).
Быть может в жабе сборка мусора и занимает секунду но в .НЕТ даже полная сборка происходит на порядки быстрее.

N>кроме того, (хотя лично я и не люблю ОРМ) многие пользуются отличными продуктами для доступа к БД (Hibernate, JDO, EJB3, из которых для .НЕТ есть только альфа NHibernate) в виде объектов, там API уровнем намного выше.
А для .НЕТ есть RFD
RFD в реальных проектах

N>кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе.
Гм... а зачем что-то еще вызывать?

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

WH>Нормальные люди используют using и соеденения возвращаются в пул сразуже после того как с ним поработали.
WH>Просто Влад говорит о том что если гдето какойто разбдолбай забудет это сделать то ГЦ за ним приберет.

а я говорю о том что ЖЦ НЕ приберет в разумные сроки. когда он будет вызван будет уже слишком поздно. соот-но финалайзер совершенно бесполезен в данном случае и вообще практически везде.

WH>Быть может в жабе сборка мусора и занимает секунду но в .НЕТ даже полная сборка происходит на порядки быстрее.

да ну? это для какого дерева объектов? если их, скажем, 15млн (типичный случай, кстати), то все равно соберет все за 10мс? кстати, а в .НЕТ вообще можно посмотреть статистику и графики в рантайме о работе ЖЦ?

WH>А для .НЕТ есть RFD

посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.

N>>кстати, именно в этом случае в finally не просто Dispose у соединения надо вызывать а еще некоторые другие действия. да и мучений то... реально try/finally блок создается за 2-3сек в нормальном редакторе.
WH>Гм... а зачем что-то еще вызывать?

ну, как сказать... вообще-то commit() надо вызывать. даже если произошли некоторые типы exceptions.

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

S>Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.

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

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

> Вот зачем на каждый цвет создавать отдельный карандаш? Лично я не вижу в этом ни малейшей рациональности.
>Троечники проектировали. Серые безнадежные троечники.
Ну все-таки смысл в этом был,
вся эта идея CreateObject\SelectObject\DeleteObject зародилась еще в
win 3.11 когда память была ценным ресурсом и процессоры были намнооого меделнее.
Я помню, читал книгу по программрованнию для win 3.11 (там еще OWL был

, и раздел посвященный GDI
был пропитан трепетным отношениям к созданиям\удалением объектов..

Кроме того GDI решает дополнительно еще другие задачи — запись в метафайлы, печать и
работу терминал клиента.

Например когда мы рисуем линию , она не рисуется сразу, а запоминается информация, что мы таким то пером, нарисовали
линию там то. Есть даже функции которые управляют эти поведением — GdiSetBatchLimit и GdiFlush.
Другое дело что эти возможности нужны только в 10% случаев ...

А вот GDI+ точно троечники писали . Не понимаю почему 250 сглаженных линий толщиной 2px рисуются ~0.3 секунды.
AntiGrain делает это за 30 ms.

... << RSDN@Home 1.2.0 alpha rev. 599>>

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

MS>Не объясняет. Если я создаю Pen в виде кисти, я в праве ожидать корректного поведения. Вот представь, что на тебе надет костюм в полоску. Ты сгибаешь руку в локте и обрати внимание — полоски идут вдоль руки. А то, что дает этот Pen(Brush) — очень похоже на детский рисунок (или дешевый комикс), в котором все полоски на костюме идут вертикально, вне зависимости от наклона рук-ног. Ну то есть вот можешь ты создать такой Pen, но зачем он вообще нужен? Что есть он, что нет — никакой разницы.

У Pen есть такая фигня как:
public void RotateTransform(float angle)

или более общий вариант:
System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)

Как раз для твоего случая сгиба рукава и полосочек

У Brush тоже самое

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

N>

посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.

NHibernate — далеко не самый удобный ORM-Tool, и далеко не самый производительный. Остает от датасетов более чем в 2 раза, в то время как RFD не отстает или даже иногда обгоняет. При чем у RFD есть потенциал выжать еще примерно 30%, и я даже знаю где (предлагал как-то типизированные ридеры для исключения боксинга простых типов)

Далее. Из опыта собственной системы. На момент разработки ГОРАЗДО удобнее всякие ограничения/характеристики/маппинг полей описывать в виде аттрибутов прямо в коде. Почему — из-за частого рефакторинга. У нас по-любому аттрибуты остаются привязанными к конкретным полям и классам. А попробуй повторить тот же трюк с NHibernate с его внешним XML-описанием...

Однако, ближе к релизу гораздо удобней внутреннее описание перевести во внешнее, т.к. такой способ лучше сопровождаем.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

От:	Sinclair	https://github.com/evilguest/
Дата:	13.12.05 06:31
Оценка:

	От:	n0name2
	Дата:	13.12.05 07:58
	Оценка:

	От:	n0name2
	Дата:	13.12.05 08:11
	Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	13.12.05 08:13
Оценка:

От:	VladD2	www.nemerle.org
Дата:	14.12.05 13:19
Оценка:

От:	McSeem2	http://www.antigrain.com
Дата:	14.12.05 14:39
Оценка:	2 (1) +2

От:	Denis_TST	www.transsys.ru
Дата:	15.12.05 20:26
Оценка: