Debugging strings with wxOSX

[Julian Smart]

Hi,

Can someone point me in the right direction for showing wxString content
when debugging wxOSX 3.x binaries with the latest Xcode? From previous
posts it seems that we should put something like this somewhere:

{(wchar_t *)$VAR.m_impl}:s

but I'm not sure where. I don't want to have to type or paste this for
every string to be shown. Maybe it should go in an lldb init file?

I did try building both with UTF-8 strings and without, but in both
cases neither of the two representations inside the string were shown as
readable text.

Thanks!

Julian

[Eran Ifrah]

Hi,
I have this line set within codelite IDE and it works for me:

type summary add wxString --summary-string "${var.m_impl._M_dataplus._M_p}"

This is the same as adding it into your lldb init file

Post by Julian Smart
Hi,
Can someone point me in the right direction for showing wxString content
when debugging wxOSX 3.x binaries with the latest Xcode? From previous
{(wchar_t *)$VAR.m_impl}:s
but I'm not sure where. I don't want to have to type or paste this for
every string to be shown. Maybe it should go in an lldb init file?
I did try building both with UTF-8 strings and without, but in both cases
neither of the two representations inside the string were shown as readable
text.
Thanks!
Julian
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

--
Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE:
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Julian Smart]

Hi Eran,

Thanks - I'm building without std string since it's waaay slower than
using wxString, so I guess I'll need to use different syntax, and it'll
be a different type.

Regards,

Julian

Post by Eran Ifrah
Hi,
type summary add wxString --summary-string
"${var.m_impl._M_dataplus._M_p}"
This is the same as adding it into your lldb init file
Hi,
Can someone point me in the right direction for showing wxString
content when debugging wxOSX 3.x binaries with the latest Xcode?
From previous posts it seems that we should put something like
{(wchar_t *)$VAR.m_impl}:s
but I'm not sure where. I don't want to have to type or paste this
for every string to be shown. Maybe it should go in an lldb init file?
I did try building both with UTF-8 strings and without, but in
both cases neither of the two representations inside the string
were shown as readable text.
Thanks!
Julian
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
To unsubscribe, send email to
or visit http://groups.google.com/group/wx-users
--
Eran Ifrah,
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

[Eran Ifrah]

Post by Julian Smart
Hi Eran,
Thanks - I'm building without std string since it's waaay slower than
using wxString

Sorry for the OT here, but your statement could not be overlooked ;)
How do you build your wx on OSX? I would like to compare the different
builds (performance wise)


Do you have some numbers?​

Post by Julian Smart
, so I guess I'll need to use different syntax, and it'll be a different
type.
Regards,
Julian

Post by Eran Ifrah
Hi,
type summary add wxString --summary-string "${var.m_impl._M_dataplus._M_
p}"
This is the same as adding it into your lldb init file
Hi,
Can someone point me in the right direction for showing wxString
content when debugging wxOSX 3.x binaries with the latest Xcode?
From previous posts it seems that we should put something like
{(wchar_t *)$VAR.m_impl}:s
but I'm not sure where. I don't want to have to type or paste this
for every string to be shown. Maybe it should go in an lldb init file?
I did try building both with UTF-8 strings and without, but in
both cases neither of the two representations inside the string
were shown as readable text.
Thanks!
Julian
-- Please read http://www.wxwidgets.org/support/mlhowto.htm
before
posting.
To unsubscribe, send email to
or visit http://groups.google.com/group/wx-users
--
Eran Ifrah,
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

--
Eran Ifrah,
Author of codelite, a cross platform open source C/C++ IDE:
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/

[Julian Smart]

Hi Eran,

Sorry, I don't have numbers and I based my decision subjectively waiting
for the Windows version to start (reading a file using a lot of small
strings). That was using a different compiler (VS 2010) but I would
imagine the standard string implementation would be similar on other
platforms. It really felt very sluggish indeed.

Regards,

Julian

Post by Julian Smart
Hi Eran,
Thanks - I'm building without std string since it's waaay slower
than using wxString
Sorry for the OT here, but your statement could not be overlooked ;)
How do you build your wx on OSX? I would like to compare the different
builds (performance wise)
Do you have some numbers?​
, so I guess I'll need to use different syntax, and it'll be a
different type.
Regards,
Julian
Hi,
type summary add wxString --summary-string
"${var.m_impl._M_dataplus._M_p}"
This is the same as adding it into your lldb init file
On Fri, Sep 5, 2014 at 12:23 PM, Julian Smart
Hi,
Can someone point me in the right direction for showing wxString
content when debugging wxOSX 3.x binaries with the latest Xcode?
From previous posts it seems that we should put something like
{(wchar_t *)$VAR.m_impl}:s
but I'm not sure where. I don't want to have to type or paste this
for every string to be shown. Maybe it should go in an lldb init file?
I did try building both with UTF-8 strings and without, but in
both cases neither of the two representations inside the string
were shown as readable text.
Thanks!
Julian
-- Please read
http://www.wxwidgets.org/support/mlhowto.htm before
posting.
To unsubscribe, send email to
or visit http://groups.google.com/group/wx-users
--
Eran Ifrah,
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
To unsubscribe, send email to
or visit http://groups.google.com/group/wx-users
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
To unsubscribe, send email to
or visit http://groups.google.com/group/wx-users
--
Eran Ifrah,
http://www.codelite.org
CodeLite IDE Blog: http://codeliteide.blogspot.com/
--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
or visit http://groups.google.com/group/wx-users

[Vadim Zeitlin]

On Fri, 05 Sep 2014 13:25:45 +0100 Julian Smart wrote:

JS> Sorry, I don't have numbers and I based my decision subjectively waiting
JS> for the Windows version to start (reading a file using a lot of small
JS> strings).

This is exceedingly surprising as wxString doesn't even use small string
optimization which would presumably be very helpful here. I'm very
sceptical about wxString outperforming std::basic_string<>, the only case
where I could see it win would be when copying a lot of big strings around
as here wxString COW would be handy. But I don't expect this to often
happen in real programs.

JS> That was using a different compiler (VS 2010) but I would
JS> imagine the standard string implementation would be similar on other
JS> platforms.

This is not really the case.

Regards,
VZ

[Julian Smart]

Actually you're right, it's still pretty snappy on Mac with std string,
and has the advantage that I can see the text in strings under the debugger.

On Windows with VS 2010 it's a different story though. I just did a
comparison. Without std string, my application in debug mode takes about
6 seconds to run and open a project file when run from outside of the
debugger. With std string, this jumps to about 12 seconds.

Inside the debugger, it takes 60 seconds to run instead of 27 seconds
for non-std string. The main problem seems to be housekeeping such as
loading application help and configuration settings. A lot of time is
spent in the string iterator.

Admittedly I'm using an ancient 1.4GHz ULV laptop which is quite good
for seeing just how slow things are. (No-one seems to want to make a
decent lightweight, quiet, powerful laptop with lots of storage and a
legible matte display these days...)

It may be that the difference would be less marked in a release build,
but that's no good for development, so I may as well stick to non-std
string at least on Windows.

Regards,

Julian

Post by Vadim Zeitlin
JS> Sorry, I don't have numbers and I based my decision subjectively waiting
JS> for the Windows version to start (reading a file using a lot of small
JS> strings).
This is exceedingly surprising as wxString doesn't even use small string
optimization which would presumably be very helpful here. I'm very
sceptical about wxString outperforming std::basic_string<>, the only case
where I could see it win would be when copying a lot of big strings around
as here wxString COW would be handy. But I don't expect this to often
happen in real programs.
JS> That was using a different compiler (VS 2010) but I would
JS> imagine the standard string implementation would be similar on other
JS> platforms.
This is not really the case.
Regards,
VZ