Есть DLL (компилируется VC++ v10-v15), которая работает в дикой (многопоточной) природе. Она и сама потоки запускает.

Понадобилось внутри написать свой конвертер GUID->TEXT.

Сделал это через, скажем так, аналог ostringstream.

	Как-то так
	//4F0F4A9E-16B8-4CD9-82F2-C7EA65C8B8A8 //0x4F0F4A9E,0x16B8,0x4CD9,{0x82,0xF2,0xC7,0xEA,0x65,0xC8,0xB8,0xA8; ss<<std::hex //<<std::uppercase <<std::setfill(ch_0); ss<<std::setw(8) <<guid.Data1 <<ch_m; ss<<std::setw(4)<<guid.Data2 <<ch_m <<std::setw(4)<<guid.Data3 <<ch_m; ss<<std::setw(2)<<unsigned(guid.Data4[0]) <<std::setw(2)<<unsigned(guid.Data4[1]) <<ch_m; for(size_t i=2;i!=_DIM_(guid.Data4);++i) { ss<<std::setw(2)<<unsigned(guid.Data4[i]); }

Вот уже неделю смотрю на этот код и меня терзают сомнения.

Некоторое время назад, один из пользователей этой DLL умудрился завалить процесс

Автор: Коваленко Дмитрий
Дата: 11.10.17

(со своим сервером) через "моя DLL"->std::locale->setlocale.

Я сейчас полез в исходники std::ostream — похоже он тоже использует std::locale

	c:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\ios
	class ios_base { locale *_Ploc; void __CLR_OR_THIS_CALL _Init() { // initialize a new ios_base _Ploc = 0; _Stdstr = 0; _Except = goodbit; _Fmtfl = (fmtflags)(skipws | dec); _Prec = 6; _Wide = 0; _Arr = 0; _Calls = 0; clear(goodbit); _Ploc = new locale; } }

То есть, похоже я могу снова наступить на грабли с std::locale.

И добавить тормоза, потому что это "_Ploc = new locale;" далеко не бесплатно. Но сейчас речь не про тормоза.

---
За 18 лет у меня ни разу не было проблем с std::ostream (ни с VC, ни с BCB).

Но вот сейчас у меня сомнения — может ну его, и написать этот конвертер GUID->TEXT полностью самостоятельно?

Все как то спокойней спать буду.

Что скажете?