daeDoubleType::memoryToString() differs in release/debug

Other Standards COLLADA
1

Hi,

SYSTEM: Windows XP

When I create a COLLADA file with floatArrays I have a problem in release mode.

In Debug mode the floats are written with a “.”.
In Release mode the floats are written with a “,”.

It seems that the following call is responsible for that:

#ifdef WIN32
// Microsoft’s stringstream implementation has weird performance issues
static char buffer[64];
—> _snprintf(buffer, 64, _printFormat, ((daeDouble)src)); <—
dst << buffer;
#else
dst << (daeDouble)src;
#endif

Any suggestions?

Regards
Wu

2

I’m a bit confused. You mean a float will get written out as “1234.567” (dot) in debug mode but “1234,567” (comma) in release mode? That’s bizarre. Does it happen for all floats or just floats in <float_array>?

I haven’t heard of this problem before. I’ll try to reproduce it tomorrow. If you have a short code snippet that demonstrates the problem that’d be really helpful.

Steve

3

Likely to be a language setting. Europe is using ‘,’ US is using ‘.’
BTW, the top of the XML file should indicate the encoding, and a fully compliant application should be able to load both encoding…

– Remi

4

I agree it’s probably a language setting. I can’t figure out why it would be different in debug from release though.

Just for the record, I can’t reproduce this on my Windows XP box. Here’s the code I’m using (a test from the domTest suite):

DefineTest(floatArray) {
	DAE dae;
	string file = getTmpFile("floatArray.dae");
	daeElement* floatArray =
	           dae.add(file)->add("library_geometries geometry mesh source float_array");
	CheckResult(floatArray);
	floatArray->setCharData("0.0 1 2.1234 345.678");
	CheckResult(dae.writeAll());
	return testResult(true);
}

I get the expected results for my language setting, in both debug and release: <float_array …>0 1 2.1234 345.678</float_array>

Steve

5

Perhaps the problem is coming from higher up. He seems to indicate this

_snprintf(buffer, 64, _printFormat, ((daeDouble)src));

as the cause of the problem. Maybe something upstream is setting _printFormat differently?