Is there a reliable way to display Strings in the debugger?

General JUCE discussion
1

Hi !

I’ve been struggling for a little while with this under Visual Studio, and a Mac user told me he had the same problem under Xcode
Coming from a country where we have a lot of non-ASCII characters, I can only applaud the move from ascii strings to UTF strings but it came at a cost : I can’t see the strings in my debugger.

I tried a few things already (win32 + intel compiler) :

  • messing with autoexp.dat
  • changing the way juce encodes strings internally ( #define JUCE_STRING_UTF_TYPE 8 to #define JUCE_STRING_UTF_TYPE 16 to match Windows internals)
  • trying to call toWideCharPointer() from the watch window of VS

Only the later method works …sometimes, not very often.

Because I can’t believe you guys are all debugging strings using DBG macros or stuff like that, I’m pretty sure there’s a way to display strings in the debugger, under Visual Studio, and under Xcode.

I’m using VS2010 with Intel compiler 13.

2

I second this. I am on XCode and can’t figure out how to look at strings either.

3

Have you seen this thread: http://www.rawmaterialsoftware.com/viewtopic.php?f=4&t=3079

Rail

4

On windows, write watch variable like this:
“str.data,su” (or whatever path to the byte array, su stands for string unicode)

On latest XCode, I’m using gdb console and it’s just a matter of setting the LANG environment, and calling “p (const char*)str.data” (or whatever path to the byte array)

5

[quote=“X-Ryl669”]On windows, write watch variable like this:
“str.data,su” (or whatever path to the byte array, su stands for string unicode)
[/quote]

It does work using VS compiler but not Intel… :?
Sorry for the noise …

6

Excuse me my ignorance, but why are you using Intels compiler with Visual studio? What’s the benefits?

7

During development, it comes with great tools (concurency analysis, profiler, etc …) and libraries (IPP which includes a fast fourier transform, math kernel, paralel building blocks) .
For production, it has better optimisations (at least on intel processors)

The problem as mentioned, is the it makes you tied with intel compiler forever. Besides it seems not to play nice sometimes with VS debugger

8

What are we talking about? Speed increase in excess of 10%? Is it worth switching to Intel just because of speed?

9

What are we talking about? Speed increase in excess of 10%? Is it worth switching to Intel just because of speed?[/quote]

Well that’s your choice, I’m not an intel salesman :slight_smile:
Most of the speed gains are in the number crunching algorithms, so if you’re developing DSP software, it can make a big difference I suppose. Beside, for FFT, you’ll probably end up using a library unless you want to reinvent the wheel and intel implementation isn’t worse than any other I guess …

10

FYI I was just watching this - MS are doing some very clever stuff in their VS2012 compiler:
http://channel9.msdn.com/Events/Build/2012/3-013

11

[quote=“jules”]FYI I was just watching this - MS are doing some very clever stuff in their VS2012 compiler:
http://channel9.msdn.com/Events/Build/2012/3-013[/quote]

The parallelisation and vectorization is truely awesome. The only thing worrying me is that it’s more platform dependant (I doubt the #pragma loop(hint) will be supported by clang or gcc and there’s no VS2012 on mac or linux, not to mention AMP stuff) .

The intel compiler, on the other hand is available on the 3 platforms, but it’s expansive (unless you’re doing open source, and it’s free) and hardware dependant (some say that it runs slower on AMD processors).

Therefore, I think it’s better to stick with OpenMP for the moment, because it’s supportedf by the major compilers on the major platforms (and that would be so nice to have a ParallelAudioProcessorGraph using OpenMP :wink: )