Здравствуйте, McSeem2, Вы писали: MS>Ладно, здесь я действительно мало чего знаю. Но вот какая штука — мне почему-то эти знания представляются неким ненужным мусором для моей работы — это то, что отнимает время, забиват голову и не дает ни малешего кайфа.
Опять же, надо отличать "не хочу знать" от "непонятно". Пока что твои жалобы выглядят, мягко говоря, неубедительно. Что, программа на С++ волшебно нашла бы файл, не лежащий рядом с ее екзешником? Студия кладет результат в bin/debug уже как минимум четыре версии, так что вряд ли ты не знал, что исполняемый файл запустится не в фолдере проекта.
Или Image.FromFile() прямо так невозможно найти, с учетом интеллисенса и документации? В жизни не поверю, что в повседневном программировании ты не пользуешься F1.
И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>У Pen есть такая фигня как: V>public void RotateTransform(float angle)
V>или более общий вариант: V>System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)
V>Как раз для твоего случая сгиба рукава и полосочек
Толку от этого нет. Надо что-то типа:
Pen.RotateToTangentOfEachLineSegment() — без параметров!
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, vdimas, Вы писали:
V>NHibernate — далеко не самый удобный ORM-Tool, и далеко не самый производительный. Остает от датасетов более чем в 2 раза, в то время как RFD не отстает или даже иногда обгоняет. При чем у RFD есть потенциал выжать еще примерно 30%, и я даже знаю где (предлагал как-то типизированные ридеры для исключения боксинга простых типов)
думаю, это особенности портирования NHibernate на .НЕТ или того что ты им неправильно пользуешься (настроек там много разных)... у RFD вообще нет и 10% тех возможностей которые есть в нормальном Жабном Hibernate.
V>Далее. Из опыта собственной системы. На момент разработки ГОРАЗДО удобнее всякие ограничения/характеристики/маппинг полей описывать в виде аттрибутов прямо в коде. Почему — из-за частого рефакторинга. У нас по-любому аттрибуты остаются привязанными к конкретным полям и классам. А попробуй повторить тот же трюк с NHibernate с его внешним XML-описанием... V>Однако, ближе к релизу гораздо удобней внутреннее описание перевести во внешнее, т.к. такой способ лучше сопровождаем.
Hibernate уже давно имеет и то и другое — на любой вкус. кстати в ИДЕЕ действительно очень мощный XML редактор.
Здравствуйте, Sinclair, Вы писали:
S>Опять же, надо отличать "не хочу знать" от "непонятно". Пока что твои жалобы выглядят, мягко говоря, неубедительно. Что, программа на С++ волшебно нашла бы файл, не лежащий рядом с ее екзешником? Студия кладет результат в bin/debug уже как минимум четыре версии, так что вряд ли ты не знал, что исполняемый файл запустится не в фолдере проекта.
Вообще-то, результаты кладутся в Debug или Relese с допотопных времен. И тем не менее, при запуске из IDE такущий каталог указывает на каталог проекта (они явно делают cd). Это было вполне логично. Зачем понадобилось менять — не понятно.
S>Или Image.FromFile() прямо так невозможно найти, с учетом интеллисенса и документации? В жизни не поверю, что в повседневном программировании ты не пользуешься F1.
Почти не пользуюсь. Если что-то надо, то Google, поскольку в MS Help'e фиг чего найдешь. Это же смешно — идем в MSDN, и не находим того, что надо (релевантность поика около нуля). Гугл как правило дает первую же ссылку куда надо.
Что же касается Image.FromFile() то сейчас опять посмотрел — нету. Причем Save — есть. Потом понял, что не так смотрел. Я-то по наивности думал как: Image img = new Image(); img.FromFile(. . .); А оказалось что метод статический! А у класса Bitmap — есть и Load и Save как члены класса. А у Image — "Load" называется "FromFile" и является статической функцией. Где логика? А еще ты что-то упоминал про засаду с блокировками файлов из за запоздалых вызовов Dispose.
S>И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
А вот получается так. Когда надо что-то сделать, берется самое очевидное, подходящее по смыслу название и оно не срабатывает! Кстати, в WinAPI — то же самое.
McSeem
Я жертва цепи несчастных случайностей. Как и все мы.
Здравствуйте, n0name2, Вы писали:
N>а я говорю о том что ЖЦ НЕ приберет в разумные сроки. когда он будет вызван будет уже слишком поздно. соот-но финалайзер совершенно бесполезен в данном случае и вообще практически везде.
Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же остановят и произведут сборку нулевого поколения. До этого ни одна сволочь не сможет сделать не шагу в управляемом мире.
А псоле сборки у меня уже будет куча хэндлов. Ну, и не надо забывать то, что сказал Вольфхаунд. ЖЦ — это подстраховка. В грамотном коде 99% будет висеть на using-ах и ЖЦ вообще не потребуется задействовать.
Скорость же сборки мусора в нулевом поколении очень высокая (несколько микросекунд). Причем чем чаще вызваешь, тем бысрее работает. Одна проблема некоторые объкты могут нечаяно протолкнуться в вледующее поколение и прийдется делать более накладную сборку других поколений. Хотя первое поколение тоже довольно дешево.
N>да ну? это для какого дерева объектов? если их, скажем, 15млн (типичный случай, кстати), то все равно соберет все за 10мс? кстати, а в .НЕТ вообще можно посмотреть статистику и графики в рантайме о работе ЖЦ?
Нулевое поколение содержит только молодые объекты. К тому же его размер подстраивается под размер кэша, так что скорость его сборки — это даже не десятки милисекунд. Это микросекунды на современных компьютерах.
N> посмотри спеку Hibernate — вопросов больше не будет. все равно что сравнивать plain text file и MSSQL в качестве СУБД.
Это ты зря. Это разные подходы.
N>ну, как сказать... вообще-то commit() надо вызывать. даже если произошли некоторые типы exceptions.
Для забытых соеденений и соеденений при работе с которыми произошли исключения нужно не commit вызвать, а откат. Вот при возвращении в пул можно проверить состояние транзакции и откатить ее если она еще активна.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, McSeem2, Вы писали:
S>>Поработай с дотнетом — и будешь находить информацию еще и быстрее чем сейчас.
MS>Ладно, здесь я действительно мало чего знаю. Но вот какая штука — мне почему-то эти знания представляются неким ненужным мусором для моей работы — это то, что отнимает время, забиват голову и не дает ни малешего кайфа.
Э... Столько времени как в этом форуме у тебя ни один дотнет не отнимет. Так что это явно натянутый аргумент.
Что до трудности получения знаний, то надо признаться, что ты лихо портировал код с FW 2.0 на 1.1 и еще разобрался как картинку с диска загрузить. Думаю, что если бы ты имел бы подобные познания в ВыньАПИ как в дотнете, то вряд ли тебе удалось бы вот так вот в лоб подобный пример переписать. Так что в этом плане все ОК.
ЗЫ
Ты вот попробуй написать простенькую программку показывающую текущий режим сглаживания шрифтов в ХРюше и позволяющую его переключить. Я тут как-то вынужден был сделать это через ВыньАПИ. Вот это был секс! Вспомнил, шо называется, молодость.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VladD2 wrote: > Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же > остановят и произведут сборку нулевого поколения. До этого ни одна > сволочь не сможет сделать не шагу в управляемом мире.
Emphasis mine.
Здравствуйте, McSeem2, Вы писали:
MS>Здравствуйте, vdimas, Вы писали:
V>>У Pen есть такая фигня как: V>>public void RotateTransform(float angle)
V>>или более общий вариант: V>>System.Drawing.Pen.MultiplyTransform(System.Drawing.Drawing2D.Matrix, System.Drawing.Drawing2D.MatrixOrder)
V>>Как раз для твоего случая сгиба рукава и полосочек
MS>Толку от этого нет. Надо что-то типа: MS>Pen.RotateToTangentOfEachLineSegment() — без параметров!
Берешь шаг в 1, согласно раpрешению устройства (т.е. 1 пиксел, например), и рисуешь каждый раз линию на эту длину.
MS>Почти не пользуюсь. Если что-то надо, то Google, поскольку в MS Help'e фиг чего найдешь. Это же смешно — идем в MSDN, и не находим того, что надо (релевантность поика около нуля).
Ну так никто и не говорил, что поисковый движок MSDN лучше, чем у Google. Зато по индексу они ищут намного быстрее. MS>Гугл как правило дает первую же ссылку куда надо. MS>Что же касается Image.FromFile() то сейчас опять посмотрел — нету. Причем Save — есть. Потом понял, что не так смотрел. Я-то по наивности думал как: Image img = new Image(); img.FromFile(. . .); А оказалось что метод статический!
Совершенно верно — не так смотрел. Надо было так:
— открываешь MSDN (у меня он вообще все время открыт)
— набираешь в индексе System.Drawing.Image
— переходишь в нижнем списке на System.Drawing.Image members
Все. Дальше пробегаешь глазами список мемберов и находишь FromFile. С пометкой S. MS> А у класса Bitmap — есть и Load и Save как члены класса. А у Image — "Load" называется "FromFile" и является статической функцией. Где логика? А еще ты что-то упоминал про засаду с блокировками файлов из за запоздалых вызовов Dispose.
S>>И на основании этого ты заявляешь, что в дотнете присутствует бесталанность, и на выяснение всего уходит масса времени. Я очень удивлен.
MS>А вот получается так. Когда надо что-то сделать, берется самое очевидное, подходящее по смыслу название и оно не срабатывает! Кстати, в WinAPI — то же самое.
Гм. А что, где-то есть такие места, где все вообще очевидно?
1.1.4 stable rev. 510
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, McSeem2, Вы писали:
WH>> public static void AddMemoryPressure(long bytesAllocated);
MS>Спасибо, но это не совсем то. Оно глобальное и работает только с памятью. А прочие ресурсы?
На самом деле чиселка bytesAllocated довольно абстрактная. В бета-версиях фреймворка писали, что это просто число, чем оно больше тем важнее быстрее его прибить. Использовать можно не только для больших кусков памяти, но и для любых дорогих ресурсов.
Здравствуйте, McSeem2, Вы писали:
MS>А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Для этого нужно чтобы вызов вышел из неуправляемой среды и вернулся назад. Имхо, в виду претензии управляемой среды на самодостаточность, чаще всё заканчивается на первом шаге.
Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
Здравствуйте, Cyberax, Вы писали:
C>VladD2 wrote: >> Гы. Если я вызову GC.Collect(0), то все управляемые потоки сразу же >> остановят и произведут сборку нулевого поколения. До этого ни одна >> сволочь не сможет сделать не шагу в управляемом мире. C>Emphasis mine.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
MS>>А там получается положительная обратная связь — надо вызвать AddMemoryPressure, чтобы GC перепугался и ринулся подметать. Тогда и деструктор вызовется. Наверное...
AVK>Тима скорее всего имел ввиду Dispose.
Не, не. Диспоз бессмысленно. Тогда вообще зачем коворить ЖЦ о доп-памяти. Он имелл в виду финалйзер. Просто ТК у нас новичёк и не знает, что при плюсовиках лучше не говорить слово "деструктор" в отношении дотнета.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Denis_TST, Вы писали:
D_T>А вот GDI+ точно троечники писали . Не понимаю почему 250 сглаженных линий толщиной 2px рисуются ~0.3 секунды. D_T>AntiGrain делает это за 30 ms.
Думаю, они рассчитывали на то что эта операция будет осуществляться аппоратно. Ведь 30 мс — это тоже неприемлемо много.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Тима скорее всего имел ввиду Dispose.
VD>Не, не. Диспоз бессмысленно.
Как раз очень осмысленно. Если программист ручками позвал диспоз до сборки мусора и в нем дорогие ресурсы были освобождены, то провоцировать преждевременную сборку мусора уже не нужно.
... << RSDN@Home 1.2.0 alpha rev. 624 on Windows XP 5.1.2600.131072>>
Здравствуйте, AndrewVK, Вы писали:
ANS>>Для этого нужно чтобы вызов вышел из неуправляемой среды и вернулся назад. Имхо, в виду претензии управляемой среды на самодостаточность, чаще всё заканчивается на первом шаге.
AVK>Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
Ага. Согласен. Это единственный случай, или есть еще примеры?
Впрочем система с материализацией стека работает. Значит проблема решаемая.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
AVK>>Типичная ситуация — почти все GUI потоки в винде ввержу имеют DispatchMessage.
ANS>Ага. Согласен. Это единственный случай, или есть еще примеры?
Есть еще — TCP-сервер например или ASP.NET приложение под IIS.
1.1.4 stable rev. 510
