Unicode, wxString, wxChar *, TCHAR *, QString etc.

[Alex Bligh]

--On 20 April 2006 09:55 +0400 Vladimir Prus <ghost at cs.msu.su> wrote:

> On Wednesday 19 April 2006 20:06, Alex Bligh wrote:
>> I seem to be able to inspect "char *" variables in the watch window. I
>> believe it's possible to inspect QString's as well.
>>
>> However, I can't seem to get kdevelop to inspect wchar *, TCHAR * (on a
>> unicode build), or wxChar *, wxString (wxWidgets string primitives etc.).
>
> Well, I plan to add support for wchar_t in future (well, let's say this
> year).  The problem currently is whether I should be fixing gdb, or give
> up and  handle this on KDevelop side.

If that was fixed, it would fix 90% of my problem. I'm presuming
if wchar_t was understood, it would also understand wchar_t *
as a pointer to a possible string of wchars, and thus similarly
TCHAR and wxChar (which are both typedef'd to wchar_t on Unicode
builds) would work, and thus also TCHAR * and wxChar *. You could
then inspect wxString and the other string class I'm looking
at (StringBase derivatives on XaraLX) merely by inspecting the
expanded structure in the variables window on the left, as they
both contain string pointers. I don't know about the STL
case, but I'd have thought this would work too.

>> Now, I know it would be unrealistic to hope for an IDE which understood
>> every possible string class, especially when the underlying debugger
>> (gdb) appears deaf to unicode, but given I'm told kdevelop will
>> examine a QString, is it possible to extend this functionality? I
>> am told that the VC++ IDE has a text file which allows (if manually
>> edited) wxString's to be supported much as it supports MFC CStrings.
>> Is there (or should there be) similar functionality in kdevelop?
>
> Did you read http://bugs.kde.org/show_bug.cgi?id=94313
> The fundamental problem is not issuing some macro invocation. I can do
> this in  current KDevelop in, ehmm, half-an-hour. The real problem is
> that if you  have:
>
>    int i;
>    ........
>    wxWstring foo;
>
> then gdb will report 'foo' as live before it's constructor has executed,
> and  so the macro author should be very carefull not to produce segfault
> when  rendering the string. Gdb seems to be come unusable in that case.

Could I not iteratively get gdb to print each character of the string?
The worst it will say is "cannot access memory at ...". This could
occur even if the string /is/ initialized (for instance if someone
munmap's the memory in question, which could be partway through the
string).

> Now, if you're:
>    - Willing to write such macro
>    - Willing to try development version of KDevelop
>
> I think we can arrange for wxString to be displayed pretty soon.

I'd already began thinking about that but I got stuck on how
to print out the Unicode bit. A more significant issue is the
type is the same on wx (wxString) whether it's a Unicode build
or not. So the macro needs to do something like ptype $foo->m_pchData
and look at the result to determine whether it's to print a unicode
string or a char * string. But that should be soluble. I may have a go
once Unicode stuff works. I've no problem trying a development kdevelop
(if it's stablish, I might even use it in anger).

Alex

-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«