Я создаю окошко и хочу чтобы мой класс обрабатывал сообщения: Code (Text): LRESULT CALLBACK WndProc(HWND hwnd, UINT msg, WPARAM wp, LPARAM lp) { if (msg == WM_CREATE) { CREATESTRUCT *p_create_ctruct = (CREATESTRUCT*)lp; CMyWndClass *p_wnd = (CMyWndClass*)p_create_ctruct->lpCreateParams; SetWindowLongPtr(hwnd, GWLP_USERDATA, (LONG_PTR)p_wnd); return p_wnd->on_create(p_create_ctruct); } if (CMyWndClass *p_wnd = (CMyWndClass*)GetWindowLongPtr(hwnd, GWLP_USERDATA)) { return p_wnd->on_window_message(msg, wp, lp); } return DefWindowProc(hwnd, msg, wp, lp); } меня интересует насколько сильно это отразится на производительности? получается что для каждого сообщения дёргается GetWindowLongPtr. я глянул на код этой апишки — системные вызовы она, вроде, не дёргает, т.е. работать должна довольно быстро. да и окошко — не заметно чтоб притормаживала отрисовка. но всё же, насколько такой способ приемлем и есть ли более разумные варианты?
вы действительно думаете что использование глобальных переменных более разумно? мне этот способ ещё больше не нравится.
maksim_ Юзай ATL/WTL чтобы не изобретать велосипедов, а если оч хочется свое, можешь посмотреть как там сделано (хотя для того чтобы кусок в стеке везде нормально работал, MS в ядре, в обработчике исключений даже специальный кейс сделал)))
Sol_Ksacap Насчет стека может это я попутал.., хотя мне всегда казалось, что atlthunk именно там аллокируется, а сейчас посмотрел, а там вроде как в хипе, но в любом случае в "как минимум в некотрых случаях неисполнимой памяти", и в KiDebugRoutine есть вызов KiCheckForAtlThunk(x,x), который проверяет не произошел ли эксепшн в thunk'е и если да -- эмулирует его -- KiEmulateAtlThunk(x,x,x,x,x), вообще я мельком смотрел, но походу как-то так.
это нормальный быстрый способ, он кажется даже в mfc юзается. >да. есть. используй глобальные переменные ужас.
вообще глобальные переменные - зло. хотя бы из-за кеширования, релоков. по-моему, использование глобальных переменных портит облик программы.
сишник и без тебя насоздает кучу глобальных переменных, ка и огромные части классов валяются как есть прямо в exe'шнике, а это просто тьма релоков. как в такой ситуации 1 ее испортит/улучшит?
хорошо. хочу я создать 2 окна одного и того-же класса. что касается: ты не давай ему создавать. чем больше глобальных переменных - тем сложнее организовать многопоточность. если у тебя проект в несколько десятков тысяч строк кода, то попробуй найди при отладке какой кусок кода её модифицировал.
1. глобальный счетчик объектов 2. указатель на динамический массив каждое окно нумеруется и из массива выбирается для каждого окна нужное значение по индексам это не возможно. он тебя и не спросит. это не лечится ты про хардварные точки останова слышал? а если отладчик умеет это не выплевывать, а логировать, то еще проще! а вообще для доступа к таким ресурсам можно заюзать бит доступа или критическую секцию.
ты представляешь себе как это будет выглядеть )) тут уж действительно лучше GetWindowLongPtr. я бы не стал так утверждать. недавно апликуху писал с базонезависимым кодом. единственное что пришлось - адреса строк восстанавливать. отладчик у меня msvc. честно говоря, я даже не знаю - можно ли в студии ставить бряки на изменение памяти. скорее всего нет. а что касается юзанья критических секций спинлоков и прочего - я это и имею ввиду - усложнение реализации.
это время компиляции что ли базонезависимым. в любом случае, могу поспорить, это не есть просто (в реализации) а вот строки это и есть те самые глобальные переменные (как минимум строки) лочим Code (Text): lock bts [x],0 jc wait разлочим Code (Text): lock btr [x], 0 че сложного? ну так возьми нормальный. olly там или Syser
честно говоря, не понял ответа. в любом случае, вопрос сейчас не в базонезависимом коде. ну, допустим. хотя, тут нужно уточнить, что строки-то всё таки read-only. это означает то, что компилятор может запихать все строки в секию кода (часто так и происходит) и не создавать дополнительные страницы в памяти при загрузке нескольких модулей. строки ни коем образом не будут мешать многопоточности. всё чрезвычайно просто и понятно. честно говоря, я даже не понял что вы тут пытались сделать... ну, я не такой спец, чтобы писать проги в студии, а отлаживать их под олькой. да и не думаю что они для этого предназначены.
ну я не сказал, что только строки. статические части классов могут валяться болванкой в тойже секции кода (или данных), копироваться в динамическую память и там чуть видоизменяться (но чаще прямо так и используются, как есть, болванкой) использовать 0 бит переменной x для синхронизации (правда нодо сперва удостовериться, что он не будет использоваться, но это мелочи. если даже используются все биты, то ни кто не запрещает создать битмап или отдельную переменную флагов) дебаговую информацию отменили?
maksim_ Альтернативных способов множество, вот только в той среде они криво написаны будут, аналогично как и этот. Среду следует выбрать такую, чтобы она обладала достаточной гибкостью для решения задачи. Иначе как в этом примере так криво и будет.
