I've come up against a gnarly problem in developing my (yet another) ASM editor (in other thread here). It has to do with memory management.
Specifically, how to handle getting selected text. I wanted to try out copying a selection the user had made in the edit window into one of my "cubbyholes". Seems simple enough, right? Well, not so much.
Since there's no such edit control message as
EM_GET_SELECTED_TEXT, what a guy would have to do is this:
- First see if there's any selection at all using EM_GETSEL
- If there's a selection, get the entire edit control's text into a buffer, say with GetWindowText()
- Use the selection positions to extract the selected text
So what if we have tens of K of text? or hundreds of K? This means we have to have a buffer allocated that's big enough for that text. (Windows is helpful here by giving us the
WM_GETTEXTLENGTH message and the
GetWindowTextLength() function to tell us how much text (in characters) is in the control.)
Here's where we have to make some design decisions. The easy way to do this would be to allocate a buffer (I'd use
HeapAlloc(), as that's what I'm familiar with) every time we want to do this operation, then de-allocate it. Easy, but wouldn't this be expensive? as well as potentially causing memory problems with all that allocating and deallocating?
Or we could initially allocate a buffer that we
think might be big enough for most cases, then compare its size to the amount of text in the control. If it's not big enough, then enlarge it using
HeapReAlloc(). My bet would be on this method, which forces us to do some bookkeeping, i.e. memory management. (Ugh.)
Of course this problem isn't limited to us assembly-language programmers: even in a very high-level language like C++, the programmer's going to be faced with some tough decisions in the memory department.
So what would y'all do here? The same problem applies to any operations on the edit control, like searching for text or loading and saving files, where we have to deal with the entire mass of text.
