Friday, August 01, 2008

Symbian Developer FAQs [Descriptors]

1. What are descriptors?
Descriptors are Symbian OS strings.

2. why are they called 'descriptors' rather than strings?
They're names as 'descriptors', because they are self describing (not literally, it means you donot have to give any parameters). Each descriptor object holds the length of the string of data it represents as well as its 'type', which identifies the underlying memory layout of the data it holds.

3. Descriptors can be used to store text?
Descriptors can be used for storing text and binary data.

4. Do they store text data as ASCII or Unicode?
It can store both types. There are two types, 8-bit and 16-bit descriptors. The 8-bit variant is used to store ASCII characters and raw binary data. while 16-bit for Unicode.

5. How do I know which I have got?
Each type ends in 8-bit or 16-bit, for example TDesC8 or TDesC16. If nothing specified then default is 16-bit [Platform specific mostly symbian supports 16-bit as default now].

6. Which width/type should I use?
If you need to use 8-bit data, for example, to call a particular API method (such as the RFile::Read() or RFile::Write() functions ), for Internet email, or to manipulate ASCII data, you should use the explicitly 8-bit descriptors. If you want to store a chunk of binary data, use the 8 bit variety too.

If you need to work with 16-bit text, for example, Java strings, and want to indicate this explicitly, use the 16-bit descriptors.

Note: In general, unless you need to make the data width explicit, use the neutral descriptors. If nothing else, your code is more readable and it may even be portable if the default character width changes on a later platform.

7. Are they NULL-terminated like C strings?
No. as the name suggests they're self-describing, descriptors know the length of their internal data. This means there’s no need for the data to be NULL-terminated to mark where the data ends. It also means that binary data can be stored in the same descriptor classes as store text data.

Note: This isn’t possible with C strings because there’s no way of distinguishing the NULL terminating character from valid binary data.

8. Can I use standard C arrays to store my text and binary data, and the C string library to manipulate them, like I have always done?
Yes you can, but symbian native suggests using literals where possible.

9. Why it is recommended to use standard C arrays in native symbian programming.
Standard C arrays are unsafe, as they have no concept of how big they are. Null-terminated strings are clunky and inefficient. What’s more, if you want to write past the end of the allocated space of a standard C string, nothing is going to stop you. This leads to all kinds of mayhem, such as data corruption

10. 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.

Agree that 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.

On Symbian OS, efficiency is paramount, so the programmer must take responsibility for memory management.

11. 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.

12. 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 on OS.

13. Is there any size limit for a descriptor?
Yes. Descriptors can be stored on the stack or heap. The normal limitations apply as for other Symbian OS variables:
* Stack descriptors should be kept small: a 256 byte limit (128 double-byte characters) is a good guide.
* Heap descriptors can be much larger, depending on the size of heap memory available on device.

Note: For Heap descriptors the layout of a descriptor object will limit the maximum size of a descriptor to 2^28 bytes (256 MB). Since each UNICODE character = 2 bytes, the maximum length of a descriptor is thus 2^27 characters.


No comments:

stats counter