Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
Это все от опыта зависит 16.01.03 22:11 Число просмотров: 1042
Автор: amirul <Serge> Статус: The Elderman
|
> а на счет VC, не нравится он мне, интерфейс какой то не
> очень дружественный :)
Вон у vim-а вообще интерфеса нет, а люди которые знают в нем что либо, кроме :q! (я знаю: Shift - ZZ - в смысле подряд два Z с шифтом :-))) ) - ставят его в один ряд с IDE от билдеров и прочих визуал сей. Некоторые говорят, что на билдере легче интерфейсы создавать, а я так даже MFC не люблю - только plain С и DlgProc (к которому все-таки и сводятся все билдеровские извраты). Да, так отчасти сложнее в простых ситуациях, но в виду полного контроля над ситуацией гораздо безболезненней разруливаются ситации сложные (именно за это я люблю C)
Мои претензии к билдеру:
1) Уж очень тормознутый, как при компиляции, так и, например, в отображении (ну не помню как это в нем называется) прототипов функций, типов переменных и т.д. при наведении мыши, автодополнении членов класса и т.д.
2) Много извращений: в частности property - действительно можно было реализовать простой перегрузкой оператора = и конструкторов.
3) Сильно большой и почти всегда более тормознутый код.
4) Если уж де-факто (ну не написали в борланде своей ОС-и со своим GDI) есть например структура, представляющая ресурсы (в частности диалог) внутри самой ОС-и, то какого хранить эти ресурсы в текстовом виде, потом динамически строить эту структуру и отдавать ее системе. Особенно мне не нравится, то что синтаксис этого псевдоязыка для описания ресурсов явно паскалеподобный - ну не нравится он мне. Извините, если кого обижу, но на паскале имхо пишут те, кому лень или не по силам выучить цэ.
Не нравится потому, что это говорит о разработчиках борлянда.
5) Много граблей, непонятно откуда возникающих и отнимающих много времени. В частности один мой знакомый почти неделю искал багу в своей проге, и в конце концов нашел багу в стандартной библиотеке (это было давно и не с билдером, а с BCC 5.02).
А вот совсем недавний случай: была структурка:
if (ядреное_условие)
continue;
---
Этот самый continue выполнялся ВСЕГДА.
После того, как пару часов промучались меняя условие, вводя промежуточные переменные и отслеживая их в дебаггере, и в конце концов сведя код к:
if (false)
continue;
---
Просто для того, чтоб проверить кто из нас глючит; оказалось, что он - в этой конструкции всегда выполнялось continue. Двадцать раз перепроверяли, нет ли там лишней точки с запятой, удаляли полностью эти строки и перенабирали полностью. В общем-то понятно, что если бы так происходило всегда, вне зависимости от контекста, бага не дожила бы до 6-й версии, поэтому мы начали менять контекст. Сначала заменили continue на {continue;} - не помогло. Помогло следующее:
if (то_же_самое_ядреное_условие_взятое_из_CVS_а) {
int a = 3;
continue;
}
Елки-палки, но на это же ушло несколько часов. Нет, я предпочитаю знать, что происходит
ЗЫ: отписать баг репорт не смогли, так как не смогли написать тестовое повторение баги, а отсылать весь проект не хотелось - коммерческий все-таки.
|
|
<programming>
|
[C++] Builder? 13.01.03 11:16
Автор: zim Статус: Незарегистрированный пользователь
|
|
как после работы с объектом Timage освободить исспользуемую им память, и если освободить то исчезнет ли изображение? Заранее спасибо.
|
|
Конечно, исчезнет. Кто ж за его отрисовку ответствовать будет... 13.01.03 17:38
Автор: Sandy <Alexander Stepanov> Статус: Elderman
|
|
|
| |
Конечно, исчезнет. Кто ж за его отрисовку ответствовать будет... 16.01.03 14:44
Автор: zim Статус: Незарегистрированный пользователь
|
|
но, много картинок, в окне слишком накладно для памяти, те более я проверял, такие виеверы как ACDSee, практически не исспользуют оперативную памяти при выводе изображений на экран, и как это у них получается....
|
| | |
Дык ACDSee не билдере писан :-))) 16.01.03 16:15
Автор: amirul <Serge> Статус: The Elderman
|
> но, много картинок, в окне слишком накладно для памяти, те
> более я проверял, такие виеверы как ACDSee, практически не
> исспользуют оперативную памяти при выводе изображений на
> экран, и как это у них получается....
Точно не на билдере - можешь ресурсы (в частности диалоги) глянуть как генерит VC и как BCB
ЗЫ: Хотя мне больше нравятся XnView или SlowView - последние версии ACDSee уж больно монстрообразны и тормознуты, а в предпоследних фич поменее.
|
| | | |
Дык ACDSee не билдере писан :-))) 16.01.03 18:06
Автор: zim Статус: Незарегистрированный пользователь
|
> Точно не на билдере - можешь ресурсы (в частности диалоги)
> глянуть как генерит VC и как BCB
>
> ЗЫ: Хотя мне больше нравятся XnView или SlowView -
> последние версии ACDSee уж больно монстрообразны и
> тормознуты, а в предпоследних фич поменее.
Меня честно говоря тоже непривлекает последняя версия, поэтому пользуюсь 3-ей, привык уже,
а на счет VC, не нравится он мне, интерфейс какой то не очень дружественный :)
|
| | | | |
Это все от опыта зависит 16.01.03 22:11
Автор: amirul <Serge> Статус: The Elderman
|
> а на счет VC, не нравится он мне, интерфейс какой то не
> очень дружественный :)
Вон у vim-а вообще интерфеса нет, а люди которые знают в нем что либо, кроме :q! (я знаю: Shift - ZZ - в смысле подряд два Z с шифтом :-))) ) - ставят его в один ряд с IDE от билдеров и прочих визуал сей. Некоторые говорят, что на билдере легче интерфейсы создавать, а я так даже MFC не люблю - только plain С и DlgProc (к которому все-таки и сводятся все билдеровские извраты). Да, так отчасти сложнее в простых ситуациях, но в виду полного контроля над ситуацией гораздо безболезненней разруливаются ситации сложные (именно за это я люблю C)
Мои претензии к билдеру:
1) Уж очень тормознутый, как при компиляции, так и, например, в отображении (ну не помню как это в нем называется) прототипов функций, типов переменных и т.д. при наведении мыши, автодополнении членов класса и т.д.
2) Много извращений: в частности property - действительно можно было реализовать простой перегрузкой оператора = и конструкторов.
3) Сильно большой и почти всегда более тормознутый код.
4) Если уж де-факто (ну не написали в борланде своей ОС-и со своим GDI) есть например структура, представляющая ресурсы (в частности диалог) внутри самой ОС-и, то какого хранить эти ресурсы в текстовом виде, потом динамически строить эту структуру и отдавать ее системе. Особенно мне не нравится, то что синтаксис этого псевдоязыка для описания ресурсов явно паскалеподобный - ну не нравится он мне. Извините, если кого обижу, но на паскале имхо пишут те, кому лень или не по силам выучить цэ.
Не нравится потому, что это говорит о разработчиках борлянда.
5) Много граблей, непонятно откуда возникающих и отнимающих много времени. В частности один мой знакомый почти неделю искал багу в своей проге, и в конце концов нашел багу в стандартной библиотеке (это было давно и не с билдером, а с BCC 5.02).
А вот совсем недавний случай: была структурка:
if (ядреное_условие)
continue;
---
Этот самый continue выполнялся ВСЕГДА.
После того, как пару часов промучались меняя условие, вводя промежуточные переменные и отслеживая их в дебаггере, и в конце концов сведя код к:
if (false)
continue;
---
Просто для того, чтоб проверить кто из нас глючит; оказалось, что он - в этой конструкции всегда выполнялось continue. Двадцать раз перепроверяли, нет ли там лишней точки с запятой, удаляли полностью эти строки и перенабирали полностью. В общем-то понятно, что если бы так происходило всегда, вне зависимости от контекста, бага не дожила бы до 6-й версии, поэтому мы начали менять контекст. Сначала заменили continue на {continue;} - не помогло. Помогло следующее:
if (то_же_самое_ядреное_условие_взятое_из_CVS_а) {
int a = 3;
continue;
}
Елки-палки, но на это же ушло несколько часов. Нет, я предпочитаю знать, что происходит
ЗЫ: отписать баг репорт не смогли, так как не смогли написать тестовое повторение баги, а отсылать весь проект не хотелось - коммерческий все-таки.
|
| | | | | |
согласен 17.01.03 10:25
Автор: zim Статус: Незарегистрированный пользователь
|
Да, согласен, билдер особенно 6 раздражает своей "интелектуальностью", пытаясь за тебя "додумать" окончание названия функций, компилид долго, и все такое, да и вообше Борландовские компиляторы часто глючат, но в них мне нравится одна особенность, удобно исправлять синтаксические ошибки, так как редектор автоматически устанавливает курсор на ошибку.
А в VC редактор только указывает номер строки, при этом индексация строк кода не производится (это немного раздражает), это мое субективное мнение, может просто потому что я мало работал с VC.
|
| | | | | | |
Наверное именно поэтому 17.01.03 13:01
Автор: amirul <Serge> Статус: The Elderman
|
> Да, согласен, билдер особенно 6 раздражает своей
> "интелектуальностью", пытаясь за тебя "додумать" окончание
> названия функций, компилид долго, и все такое, да и вообше
> Борландовские компиляторы часто глючат, но в них мне
> нравится одна особенность, удобно исправлять синтаксические
> ошибки, так как редектор автоматически устанавливает курсор
> на ошибку.
Это одно из проявлений интеллектуальности борлянда. Он иногда делает, то чего мне не надо без спросу. Не обязательно сразу после компиляции я захочу кинуться к месту возникновения ошибки. Например, если я нахожусь в начале блока/функции и при компиляции узнаю, что некоторая переменная не объявлена, а меня кидает к первому ее использованию. Но это не совсем то, чего я хочу, хотя борланду так кажется.
> А в VC редактор только указывает номер строки, при этом
В VC чтобы перейти к какой либо конкретной ошибке нужно или кликнуть по ошибке в окне вывода, или нажать F4 (следующая ошибка) Shift-F4 (предыдущая). Есть еще несколько способов. А когда я начал просматривать все команды (из Customize->Keyboard), в том числе и те, которым просто не хватило клавиш - я прозрел. Какую бы неприязнь я не испытывал к Microsoft-у, VC это единственный их продукт, который мне нравится. Более того, это самый удобный IDE, с которым я работал. Сразу скажу, что работал я со многими (и не только под виндой и не только на PC), причем начинал именно с борландовского C 3.1, после которого недолго думая пересел на 5-й, в том числе и из-за предвзятого отношения к Microsoft. Но позже я все-таки решил попробовать VC, о чем не жалею: у нас-то что BC, что VC стоят 2 бакса за компакт.
> индексация строк кода не производится (это немного
> раздражает), это мое субективное мнение, может просто
> потому что я мало работал с VC.
|
| | | | | | | |
ладно уговорил 17.01.03 17:29
Автор: zim Статус: Незарегистрированный пользователь
|
|
Ну что ж, наверное все таки поставлю еще раз VC и хорошенько пошарю по все настройкам.... А на VC как с картинками работать
|
| | | | | | | | |
А хрен его знает :-))) 17.01.03 23:13
Автор: amirul <Serge> Статус: The Elderman
|
> Ну что ж, наверное все таки поставлю еще раз VC и
> хорошенько пошарю по все настройкам.... А на VC как с
> картинками работать
Вообще все API в твоем распоряжении - MSDN под руки и в путь. Вот первый попавшийся пример оттуда (MFC мать его :-))) )
CMyWnd::OnRButtonDown(int nFlags, CPoint mouse)
{
CMenu menu;
CImage image;
// Code to create menu and load/create image goes here
CBitmap* pBitmap = CBitmap::FromHandle(image.m_hBitmap);
menu.AppendMenu(0, ID_SOMECOMMAND, pBitmap)
menu.TrackPopupMenu(TPM_RIGHTBUTTON | TPM_LEFTALIGN, mouse.x, mouse.y, this);
}
---
Если разобраться, то борляндовские компоненты и мелкософтовские интерфесы суть одно и то же. С той лишь разницей, что ребята из M$ лучше знают свою ось и лучше финансируются.
Ненамного сложнее, чем у борланда, но я бы наверное сам ковырялся в чем-нить типа DirectDraw - для повышения эффективности и полного контроля за ситуевиной.
Еще на твоем месте я бы поискал на sourceforge "Developer's Image Library" - DevIL. Она идет не только на VC - портабельность вроде даже не только под вынь (точно не уверен, но кажется так и есть), не то что VC - BCB. А набор фич и поддерживаемых форматов меня мягко говоря впечатлил. Распространяется под LGPL. А вообще надо почаще на sourceforge заглядывать (это и себе тоже пожелание) - там ну очень много интересного. Или в этом случае тоже не приемлим чужой код?
|
| | | | | | | | | |
Понятно :-))) 21.01.03 10:19
Автор: zim Статус: Незарегистрированный пользователь
|
>Или в этом случае тоже не приемлим чужой код?
Нет как раз в этом случае я себе не доверяю, и прийдется вс таки идти на sourceforge :-)))
|
| | | | | |
Один огромный плюс билдера 17.01.03 00:46
Автор: amirul <Serge> Статус: The Elderman
|
Билдер стоит 60 баксов, а DevStudio полтора косаря.
Но все-таки это не для нашей постсовковой реальности
|
| | |
Ну давай головой вместе подумаем ;-) 16.01.03 15:20
Автор: HandleX <Александр М.> Статус: The Elderman
|
Итак, винда прислала твоей многостродальной софтине сообщение WM_PAINT. Это значит, что винда определила, что некий кусок окна в твоём приложении нуждается в прорисовке. Это может произойти, к примеру, когда часть окна была закрыта окном другого приложения, а тут мы его свернули... Итак, надо прорисовывать... Что обычно делаем в Builder'e с классами VCL (TImage который) ? Правильно, в конце концов вызывается метод TCanvas->Draw, который отрисует некий TGraphic. А на нижнем уровне, на уровне функций Windows GDI отрисовывается в конце концов Bitmap или Metafile, который обязательно должен быть где-то в оперативной памяти.
Теперь далее. Скорей всего это Bitmap... или DIB... ACDSEE читает граф. файл, оптимизирует его для экранного разрешения и хранит в памяти. Предположим, он может хранить в памяти одновременно не более трёх. При разрешении 1024х768 размер 32-битного изображения будет 1024*768*4(байта) будет 3145728 байт. Итого 9 мегабайт. Много это или мало для современных компьютеров — это ещё тот вопрос.
Что за изображения ты грузишь в TImage? Если они высокого разрешения, то могут сильно напрягать твоё приложение и систему в целом. Загружаемое изображение надо оптимизировать под экранное разрешение.
Надо заметить, что классы VCL для работы с изображениями не предназначены для профессионального использования. Да и ты тоже нашёл с чем сравнить — с ACDSee, эту софтину ребята вылизывают много лет и имеют неплохие бабки с неё. Работают они с OS на низком уровне.
Читай документацию по функциям Windows GDI, DIB и проч.
|
| | | |
Ну давай головой вместе подумаем ;-) 16.01.03 18:02
Автор: zim Статус: Незарегистрированный пользователь
|
Ну, оптимизировать картинку под размер окна мне не нужно, так как работаю с пикселами на уровне битов, поэтому картинка нужна полностью в оперативной памяти, но желателино чтобы она содержалась не в TImage, а в динамическом массиве, так как обращение к байтам картинки помещенной вTImage в цикле, немного усложнено (приходится пересчитывать координаты пкселей из двухмерных в одномерные, а это значительно замедляет весь процесс), а хранить два изображения (одно в TImage, одно в массиве) накладно, может посоветуеш как отображать и регенерировать картинку не исспользуя TImage?
А на счет ACDSee я все понимаю, просто была интересна технология.
|
| | | | |
Если делать битмэп то винда его запросто может в видеопамять засунуть- типа 2D ускорение 17.01.03 01:48
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
|
| | | | | |
это интересно 17.01.03 10:29
Автор: zim Статус: Незарегистрированный пользователь
|
|
Правда, а как это сделать, и как потом оз памати карты этот битмап извлечь, мне ж потом преобразованый битмап сохранить нужно, тем более преобразовать его нужно всего один раз, в чем тогда будет состоять ускорение?
|
| | | | | | |
это интересно 17.01.03 11:43
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
пробразовывать ты его будешь путем копирований в другие hdc (BitBlt - функция аппаратно поддерживаемая практически всеми более-менее современными видеокартами), растяжения/сжатия(StretchBlt), повороты PlgBlt - все это делается на уровне АПИ не с самими адресами памяти а HBITMAP. Если нужны конкретные цвета пикселей - делается GetDIBits. А откуда берутся пиксели - вопрос только винды и драйверов видюхи.
|
| | | | | | | |
это интересно 17.01.03 17:24
Автор: zim Статус: Незарегистрированный пользователь
|
|
но мне не нужны не повороты не растяжения, мне необходимо преобразовать только младхие биты цветов пикселей, а потом преобразованую картинку сохранить, вот и все.
|
| | | | | | | | |
как преобразовать? 17.01.03 23:20
Автор: Killer{R} <Dmitry> Статус: Elderman
|
|
Между прочим в том же BitBlt есть куча методов рисования картинки - и XOR, и OR, и AND и помудренее... А вообще если хочешь на API делаешь битмэп. И если очень хочешь оптимизировать память - вытаскиваешь из него в буфер строки GetDIBits делаешь с ними в памяти что хошь а потом засовываешь в битмэп - SetDIBits
|
|
|
подробно о проекте
Анализ криптографических сетевых...
