Thursday, May 05, 2005
4. Memory management and descriptors
Do descriptors automatically resize themselves if I need more memory?
No. The memory allocated for a descriptor is fixed, and specified on construction. They do not resize themselves dynamically, although you can re-allocate memory for an HBufC heap descriptor. But this has pitfalls of its own as will be described in 20. How do I use a heap-based buffer descriptor?
Why? It would be more useful if it were automatic.
It would make life easier for the programmer, but it could also make them less efficient, and it would require complex code to be exception-safe. Think of it like this:
Most descriptor modification methods can potentially require an increase in the amount of memory allocated to the descriptor. If the descriptor classes themselves did this, most of the methods would have to be able to leave, or would be surrounded by less-than-efficient TRAPs. This is quite an overhead when, in the majority of cases, a fixed size string is fine.
On Symbian OS, efficiency is paramount, so the programmer must take responsibility for memory management.
What happens if I overrun a descriptor’s allocated space?
You will get a panic in both debug and release builds. The panic will be part of the USER category which can be found documented in [reference 2]. It can be assumed that no illegal access of memory has taken place and that no data was moved or corrupted. However, your code will rapidly cease executing, and if you are running in a system thread, you could even reboot the phone.
Isn’t that a bit drastic?
Drastic maybe, but safe. You will not be overwriting any memory that you shouldn’t be, which avoids the difficult-to-find errors this can cause for C strings.
Do descriptors perform garbage collection?
No. In the same way that descriptors do not perform allocation or re-allocation, they do not perform garbage collection, because of the extra overhead that would carry.
No. The memory allocated for a descriptor is fixed, and specified on construction. They do not resize themselves dynamically, although you can re-allocate memory for an HBufC heap descriptor. But this has pitfalls of its own as will be described in 20. How do I use a heap-based buffer descriptor?
Why? It would be more useful if it were automatic.
It would make life easier for the programmer, but it could also make them less efficient, and it would require complex code to be exception-safe. Think of it like this:
Most descriptor modification methods can potentially require an increase in the amount of memory allocated to the descriptor. If the descriptor classes themselves did this, most of the methods would have to be able to leave, or would be surrounded by less-than-efficient TRAPs. This is quite an overhead when, in the majority of cases, a fixed size string is fine.
On Symbian OS, efficiency is paramount, so the programmer must take responsibility for memory management.
What happens if I overrun a descriptor’s allocated space?
You will get a panic in both debug and release builds. The panic will be part of the USER category which can be found documented in [reference 2]. It can be assumed that no illegal access of memory has taken place and that no data was moved or corrupted. However, your code will rapidly cease executing, and if you are running in a system thread, you could even reboot the phone.
Isn’t that a bit drastic?
Drastic maybe, but safe. You will not be overwriting any memory that you shouldn’t be, which avoids the difficult-to-find errors this can cause for C strings.
Do descriptors perform garbage collection?
No. In the same way that descriptors do not perform allocation or re-allocation, they do not perform garbage collection, because of the extra overhead that would carry.
Comments:
<< Home
Agreed. I could never understand how this could be a good design decision, because you will either waste programmer time (and introduce a lot of potential bugs) or you will waste more memory than with auto resising strings/descriptors. And obviously programmers are lazy, so it will result in wasting memory and also introducing bugs, as we fall back from the C++ strings to basically the C char[]'s. The fact that descriptors won't allow you to overwrite foreign memory won't earn us much here as compared to standard C char[]'s on as we usually use them on systems that have memory protection (as opposed to Symbian), so an overwrite will usually crash the application, and only that application. Maybe a bit later, but it will.
I fail to see why they weren't able to provide at least a few 'L' methods that auto resize the descriptors. The most needed one is of course Append. We could have an Append and an AppendL, though there is no point in doing so, because I don't think that fixed length strings (let's call them char[]'s....) are that useful. All operations that change their length will result in a check for size and will need to handle optional reallocation anyway. And that will result in playing with the CleanupStack and that will result in a method that may leave, so we gained nothing but lost a lot here.
Post a Comment
I fail to see why they weren't able to provide at least a few 'L' methods that auto resize the descriptors. The most needed one is of course Append. We could have an Append and an AppendL, though there is no point in doing so, because I don't think that fixed length strings (let's call them char[]'s....) are that useful. All operations that change their length will result in a check for size and will need to handle optional reallocation anyway. And that will result in playing with the CleanupStack and that will result in a method that may leave, so we gained nothing but lost a lot here.
<< Home
