(solved) cout with a double crashes/exits, while printf works

Hello all,

I am using devkitPPC version 16a (taken from the .ini file) and have a little problem with printing a double on the Wii.
The code looks like this:

double norm_x = delta_x/delta_max; 
if(norm_x > 1){ norm_x = 1; };
if(norm_x < -1){ norm_x = -1; }
double angle_x = (asin(norm_x)*180.0) / 3.1415

Now, if I want to print out the angle_x variable with cout:

cout << angle_x << endl;

I get returned to the HBC without even seeing a pixel of text drawn.
However, if I use printf:

printf("%f",angle_x);

it works flawlessly.

Can you tell me why that is the case and what I did wrong ?

If you need to look at the whole file, you can get it here:
[tom-f.org]
The code begins at line 166.

edit:
I just had the same problem with this piece of code:

u32 type;
	int res = WPAD_Probe(wiimote, &type);
	if(res == WPAD_ERR_NONE){
		return true;
	}

If i would remove the if() or the WPAD_Probe(), it would run fine, else not. However, after several tries it ran fine -- I begin to suspect that the memory gets overwritten in some parts. Is there a way to get something like the linux commands ltrace or strace into the binary to debug it ?

edit2:
Alright, the problem (sort of) solved itself. It was caused by the sendelf.exe application I used to upload the .dol to the Wii, switching to wiiload fixed this.
I'll keep the problematic .dol file in case the authors of sendelf want to use it for debugging (download here).



Edited 3 time(s). Last edit at 01/10/2009 11:23PM by Alanceil.

Since I am the author of sendelf, I would love to know wtf went wrong. You are using the latest version, right?

This is why wiiload needs a CRC.

Yes, I was using the latest version (I also sent you a PM about this).

However, after sleeping a day on it, it dawned on me that this was most certainly my own stupidity.
I changed the main while(1){...} loop to a while(!button_home_pressed){...}, but forgot to initialise the structs that record the button-presses before that. In result, depending in which condition the memory was from the program before, it sometimes reported 'yes' and otherwise 'no'.

So, I don't think your program is at fault here - I'm sorry for the false alarm (and a bit embarrassed, too...).