Descriptors FAQ

Thanks. Yes, that's a great idea. Next time I do some updates (which should be soon, I hope) I'll tinker with the diagram.

Thanks for the suggestion.
 

"is the size of the descriptor known at runtime and smaller than 256 bytes ?" - should it perhaps be "compile time", when the templates get expanded ? Isn't the size always known at runtime ?
 

Yes, I think that's a good point.

I guess you could argue that it depends at what point of runtime you mean. If you're reading from a file selected by a user, you don't know how much data you'll need *until* they select it, even though the code is "at runtime" before selection. But I take your point and will incorporate it.

I promised to make changes ages ago and still haven't done it. I will do so when I next get a chance!
 

If TBuf & TBufC aren't intended to be used with data length < 256, why this descriptors weren't designed to have 2-byte field (1 for the type & another for the length) instead of 4 (which would have saved 2 bytes per each descriptor?
 

Good point Alexis. I think one reason would be that you can put more than 256 bytes worth of data in a TBuf if it is itself a member variable in a heap-based class.

So you could have a CData class, for example, which acquires a large chunk of data from somewhere and stores it a TBufC buffer descriptor. Because CData is always created on the heap, so is the buffer descriptor, so it's OK to go beyond the usual limit.

Another reason is that the base class possesses the member data that you're suggesting is truncated for type and length - but this base class is also used for descriptor types that can be any length. And 4-byte alignment is probably another factor.

But that is a good question, thanks for pointing it out.