More Strings and Things

Minor changes to the WoopsiString class. It now reallocs with the necessary size plus 32 chars, which should reduce the number of reallocs required. I’ve fixed an off-by-one bug in the remove() method, and added some more bounds checking in the same place.

The Text class, used by the MultiLineTextBox to store its contents, now inherits from the WoopsiString class. This means all of the string functions are stored in a single class instead of being duplicated in two places, and it also means that the Text class gets all of the new memory management code.

As a result of this, the MultiLineTextBox now has a removeText() method. The keyboard’s backspace key can now be wired up, which I’ve demonstrated in the keyboard example.

Next on the list - finish cursor support in the TextBox. I can either leave the way it works as it is, or follow Jeff’s advice and have multi-character selection in addition to the cursor. In any case, it might be handy if tapping a textbox with the stylus jumped the cursor to the click position.

Once that’s done, I need to add cursor support to the MultiLineTextBox.


Jeff on 2008-10-10 at 23:15 said:

When you say ‘plus 32’, is it the original size+32 or is it rounded up to the nearest multiple of 32?

Some malloc’s work better if you ask them for block sizes that are powers of 2, some like multiples of 8 (for alignment), etc.

Sadly, I don’t know what devkitpro likes - it might be worth experimenting - write a problem that allocates a block, then iterate around using realloc() to changes its size up by one byte, and looking to see when the returned pointer actually changes…

Jeff on 2008-10-10 at 23:15 said:


“problem” = “program”

Stewart Griffin on 2008-10-10 at 23:20 said:

It seems there has been a sudden spike in your Whoopsi and blogging activity. I guess that’s what happens when you take on a life of leisure and leave others to maintain your code :)

ant on 2008-10-12 at 08:29 said:

It’s the original size + 32, not rounded up. I’m using C++ style “new” and “delete” to allocate/deallocate memory, which means I can’t use realloc(). I’m allocating a new block of memory with “new” and, manually copying the string to the new array.

realloc() would be slightly counter-productive for string insertions, as it would copy the entire string to the new location. I’d then need to move a chunk of the string to a new point in the array to perform the insertion. Instead, my insertion routine automatically creates the gap ready for the second string. In the worst-case scenario (inserting at the start of a string), the realloc() method would copy the entire string twice, whilst I only copy it once.

ant on 2008-10-12 at 08:37 said:

@Stewart: Life of leisure?! I have to get in before 9am every day to get a parking spot, so I’m in for 8 hours most days, except for Tuesdays when I’m in for 11 hours. However, the majority of the work I’m having to do is simplistic (except for the maths I’m catching up on for the graphics class - not taking the course, but sitting in on the lectures) so that leaves me with a few hours every day to tinker with Woopsi.

It’s a bit of a strange arrangement - since I can’t connect to the SourceForge SVN repo, install DevKitPro or run a VM, I’m writing code in KDevelop, emailing it home and then testing it when I get back.

Jeff on 2008-10-17 at 00:33 said:

Actually, realloc() shouldn’t copy memory around if it doesn’t need to. Since malloc’d blocks of memory are typically next to one another, realloc can detect whether it can simply “grow” the existing block (by coalescing the following empty space). Most implementations should be able to do this, though I’m not sure about devkitpro.

ant on 2008-10-17 at 07:44 said:

Ah, in that case realloc() is probably worth exploring. I’ll get the class switched over to C-style mallocs and have a look at what realloc does in various scenarios.

ant on 2008-10-17 at 10:57 said:

Been playing with realloc() in Linux, and it does indeed seem to just extend space if possible. Unfortunately, I don’t think there’s a way you can tell what realloc() will do before you call it, so although it will improve the append and set operations, it may reduce the speed of the insert operation. I might switch to realloc for append and set, and use malloc for inserts.

ant on 2008-10-19 at 12:42 said:

Looking through the code, both setText() and insert() in WoopsiString will potentially be slower if I use realloc(), as they may end up performing unnecessary copy operations instead of just growing the memory region. Only append() really benefits, but as I’m already mimicking the behaviour of realloc() to an extent by allocating more memory than I need to, it won’t necessarily bring me any benefits.