Re: this cast to const char*
On 06.05.11 01.11, Balog Pal wrote:
[CString binary compatible to const char*]
It is more than accident. Not compiler but library magic. At least the
CString implementations I looked at (up to VS6, MFC4.2) the
implementation used a string-holder struct with some header (having
refcount among others) and the string data itself at the tail (variable
lendth). And CString itself had no data elements but a sole pointer.
That was set to point to start of the sting data inside the mentioned
holder. Member functions used pointer-math to substract offset and get
to the full structure.
[...]
I did not see it specifically documented as a feature of CString, so it
is unofficial heuristic at best, but the intention to make and keep it
work is IMO clear.
I made my own string class implementation to work in the same way
(without knowing the CString implementation at this time). But I did
this for a completely different reason. It makes the conversion from the
string class to const char* very cheap. Otherwise the stored pointer
must always be compared against NULL before adjusting it to the real
string content. On the other side accessing the string length and the
ref count at negative offsets does not cause any significant overhead on
most platforms.
Furthermore, using this memory layout enables array classes in the same
library to simply cast from CString* to const char** by a reinterpret
cast, which would necessarily cause an allocation otherwise.
So I would not bet that the implementation is done due to the printf
compatibility. This is most likely a spin off.
The visual compiler painfully lacks similar analiser as gcc's
__attribute__(format) that checks the types and format string
components, my usual tech s to use format helpers consistently. I.e:
printf("int:%d, long: %ld, str: %s", f_d(i), f_ld(lo), f_s(str));
Well, C++ and printf...
There is still no reasonable replacement in the standard. One must be
stoned to use the iostream output operators, because besides being type
safe they create completely unreadable code, at least if you use
different formatting (like hex and decimal) concurrently.
Marcel