why oh why does calling Right, Left or Mid on a TDes give you a TPtrC?
| Mon, 2005-08-29 12:33 | |
|
Ok it makes sense that calling Left, Right or Mid on a TDesC returns a TPtrC. But am I the only one to think it seriously sucks to have these methods return TPtrC when called on a TDes. Why can't the TDes class override these methods so that they return a TPtr? Anyone has an opinion on the matter? Maybe there is a good explanation why? Any descriptor advocates care to share their knowledge? Thanks, Nikolas. If we fall down it's so we can learn to pick ourselves up. |
|






Forum posts: 68
void method(TDes& aString)
{
  aString.TrimAll() ; // that's fine
  (aString.Left(3)).TrimAll ; // this should be fine but it's not because Right returns a TPtrC
}
If I wanted to accomplish the above I would have to go through the shenanigan of copying the right part of the data into a buffer and then creating a TPtr to the buffer and then calling TrimAll on the TPtr. But then that doesn't modify aString directly (it only modifies the buffer) so if I wanted to modify aString directly, I would have to copy my buffer back into aString thus overwriting the original contents of aString. Ugh.
Any comments? Of course I might be just horribly confused but I think from a logical point of view, it's terribly inconsistent to have Right, Left and Mid return a TPtrC and not a TPtr when called on a TDes.
Thanks,
Nikolas.
If we fall down it's so we can learn to pick ourselves up.
Forum posts: 51
Even if this was intended, it couldn't be implemented because it would need to update the length information of the original descriptor, but it doesn't have a link to where that is kept.
B
Forum posts: 683
((aString.Left(3)).Des()).TrimAll()