Locale for large numbers (comma)

[alas2]

Seems the writer uses the current locale, but the reader does not consider the current locale.

For example, this a sample of the writer. The actual numbers are 315774.82459647837095 5811495.505408138036728 2.186643443248281

#6= IFCCARTESIANPOINT((315,774.82459647837095,5,811,495.505408138036728,2.186643443248281));

The reader does not read (315,774.82459647837095) as a single value, it is read as 315.

I think, wherever string streams are used to output or input numbers need to set '.imbue(std::locale::classic())' to be independent of locale

[ifcquery]

I think 1000 comma separators are not according to the STEP standard.
This is a regular cartesian point:
#12=IFCCARTESIANPOINT((0.,0.,12345.6));

How would it look like with 1000 comma separators?
#12=IFCCARTESIANPOINT((0.,0.,123,45.6));

It wouldn't be possible to figure out which comma is a number separator, and which one is a 1000 separator

[alas2]

@ifcquery ,

That's right. That's why the IFC writer should NOT use comma separators. Should write as in your example (#12 first line) not (#12 the second).

[ifcquery]

Ok, now I understand. I never ran into that problem, but it makes sense.
I added it to WriterSTEP::writeModelToStream
Thanks for the suggestion

[alas2]

@ifcquery

I think, it has to be in WriterUtil.cpp as well

void appendRealWithoutTrailingZeros(std::stringstream& stream, const double number)
{
std::ostringstream temp;
temp.imbue(std::locale::classic()); // Here

Also, here in the same function but near the end

std::ostringstream temp;
**temp.imbue(std::locale::classic()); // and here**

[ifcquery]

Yes, correct