Debuggable string

General JUCE discussion
1

Hi,

Is it possible to add a JUCE_DEBUG_STRING macro, that, once defined, force Juce’s string to use UTF16 on Win32, and UTF8 on linux ?

Recently, I’ve been debugging latest tip code on Windows, and not being able to actually see the content of a string in the debugger is a real PITA.

2

Have a look at JUCE_NATIVE_WCHAR_IS_UTF16 in the latest tip.

3

No - that won’t do it. I’m gradually moving towards a string class that can use different encodings, but it’s not there yet.

4

Well, latest tip does this:

#if JUCE_WINDOWS && ! DOXYGEN
#define JUCE_NATIVE_WCHAR_IS_UTF8      0
#define JUCE_NATIVE_WCHAR_IS_UTF16     1
#define JUCE_NATIVE_WCHAR_IS_UTF32     0
#else
/** This macro will be set to 1 if the compiler's native wchar_t is an 8-bit type. */
#define JUCE_NATIVE_WCHAR_IS_UTF8      0
/** This macro will be set to 1 if the compiler's native wchar_t is a 16-bit type. */
#define JUCE_NATIVE_WCHAR_IS_UTF16     0
/** This macro will be set to 1 if the compiler's native wchar_t is a 32-bit type. */
#define JUCE_NATIVE_WCHAR_IS_UTF32     1
#endif

#if JUCE_NATIVE_WCHAR_IS_UTF32 || DOXYGEN
/** A platform-independent 32-bit unicode character type. */
typedef wchar_t        juce_wchar;
#else
typedef uint32         juce_wchar;
#endif

So, it’s not what I’m asking. I’m asking something like this in juce_config.h

#if defined(JUCE_DEBUG) && defined(JUCE_WINDOWS)
    #define JUCE_DEBUG_STRING 1 // Enabled this on debug build so the strings are UTF-16 and not UTF-32
#endif

and in characted function.h

#ifdef JUCE_DEBUG_STRING
typedef wchar_t juce_wchar;
#elif JUCE_NATIVE_WCHAR_IS_UTF32 || DOXYGEN
/** A platform-independent 32-bit unicode character type. */
typedef wchar_t        juce_wchar;
#else
typedef uint32         juce_wchar;
#endif

The idea is that strings will defaults to official wchar_t type under debugger.

5

The problem with holding the string as anything other than full unicode is that it prevents random access, so a whole bunch of string manipulation ops need to be rewritten to deal with that. I’ve got a few ideas on how to do it, but haven’t got there yet. Will do soon.

6

Well if you can’t think of anything, you could always just store them as utf-16 and still allow random access (like the original Windows Utf-16 String) , just for debugging. I mean, yeah in theory it will screw up with high code points but in practice, it will allow debugging. That’s if no better solutions present themselves.

7

Any progress on this ? Not being able to view a string in the debugger is more that a PITA, it is very, VERY upsetting… :evil:

Edit: Trying to fix it by adding a debugger extension, but of course, since everything is always private in JUCE, that doesn’t work either…

8

The debugger doesn’t mind if it’s private AFAIK, at least under visual studio 2008.

One “trick” I use (in VS) is to write the expression "myString.text.data,100s"
This displays the 100 first characters of the string as an array . Not optimal but works

9

I’m in Android-land at the moment but will go back to working on strings soon. I think Cyril’s suggestion is very good though - it’s a one-line change and will work just fine.

10

I’d rather not change to codebase to do it, but if that what it’s gonna take I’ll have to. Meanwhile I found a way to view the native (UTF32) String in the debugger watch window through the expression (if s is the juce String):

s.toUTF16(),su

so I figured I’d put that in autoexp.dat, i.e.:

juce::String{
preview ([$e.toUTF16(),su])
stringview ([$e.toUTF16(),sub])
}

but that does not work (!?). Anyone autoexp.dat savvy that know why ? :slight_smile:

11

I think in autoexp, you can only use data members, not methods

12

[quote=“robiwan”]s.toUTF16(),su

so I figured I’d put that in autoexp.dat, i.e.:

juce::String{
preview ([$e.toUTF16(),su])
stringview ([$e.toUTF16(),sub])
}

but that does not work (!?). Anyone autoexp.dat savvy that know why ? :)[/quote]

Dude…what is all this? Is this Visual Studio 2008? wow! Where are the docs on this?

13

There’s not much explicit docs on autoexp.dat, but I’ve found this URL helpful:
http://pontusmunck.com/2010/01/19/visual-studio-debugging-tricks/

14

Exactly what do I need to change so that I don’t get a ton of compile errors/warnings (f.i. juce_String.h (131,134) and juce_CharPointer_UTF16.h (160) ) ??

15

Finally bit the bullit. If you want to see the native Juce string in Visual Studio, add this in the [autoexpand] section of autoexp.dat:

juce::String=$ADDIN(jucedbg.dll,JuceString)

and D/L the attached (zipped) DLL and place it where devenv.exe resides (you need to restart VS after autoexp.dat is changed)

Btw. if the debug string stuff will find it into the codebase, that would be great, since the Visualizer stuff would work nicely.

/Rob

16

erm… since the changes I checked in last week, the strings are all encoded as UTF8, so the debugger just shows them without any need for any messing about. Sorry, I thought you’d have noticed that change.

17

Nope… haven’t done any pull lately… Thanks, though :slight_smile:

18

Ok, what do you mean ? Just did a git pull, and fixed a myriad of compilation errors and debugger shows: “{empty={…} text={…} }”

unless the following is in autoexp.dat ([Visualizer] section):

juce::String{
preview ([$e.text.data,s])
stringview ([$e.text.data,sb])
}

…
/R

19

fwiw, it all works on my machine since updating the other day…

20

Not much I’m afraid, there was a lot of toCString() places in the code which I admit should be toUTF8() anyway. But that’s how it is :slight_smile: