Chapter 1

TBuf helloWorld(_L("hello"));
greetEntity(helloWorld, _L("world!"));
I've used an alternative format for the literals used to initialize descriptors here: _L produces
a TPtrC, which describes the text in the string. So greetEntity() gets called with
TBuf and TPtrC parameters, which suitably match its prototype requirements.
We saw when discussing TDesC how the current data length is always the first machine
word of a concrete descriptor class, allowing the same Length() implementation in all
classes. In TDes and its derived classes, the maximum allowed data length is always the
second machine word, so TDes::MaxLength() is implemented identically for all
modifiable descriptor classes.
The address of the first byte of data therefore varies depending on the concrete type of the
descriptor class: sometimes it's the first byte after the length; sometimes it's the first byte
after the maximum length; sometimes it's contained in a pointer after the length. This is why
TDesC::Ptr()is implemented differently for each descriptor class.
Every other TDesC or TDes function depends only on Ptr(), Length(), and
MaxLength(), so they can be implemented without any dependence on the concrete
descriptor class.
5.2.6 Literals Again
We've now seen two kinds of literal descriptor:
� _LIT, which associates a symbol with a literal value and produces a TLitC, which is
not derived from TDesC
� _L, which produces a TPtrC from a literal value and can be used without a name.
At first sight, _L is more attractive, for precisely the two reasons I mentioned above. It was
the only type of literal supported until Symbian OS v5.0, when _LIT was added. This is now
preferred to using _L in most circumstances: let's see why.
Here's how _L works. It is defined as
#define_L(string) TPtrC((const TText*) string)
So that
const TDesC& helloRef = _L("hello");
It does three things:
� When the program is built, the string, including the trailing NUL, is built into the
program code. We can't avoid the trailing NUL because we're using the C compiler's
usual facilities to build the string.
� When the code is executed, a temporary TPtrC is constructed as an invisible
automatic variable with its pointer set to the address of the first byte of the string and its
length set to five.
� The address of this TPtrC temporary is then assigned to the const TDesC& reference,
helloRef, a fully-fledged automatic variable.
This code works provided either that the reference is only used during the lifetime of the
temporary – that is, during the lifetime of the function – or that the TPtrC pointer and length
are copied if the descriptor is required outside this lifetime. This is usually OK, but you get
the feeling that you're walking on eggshells.