क्या सी ++ 0x में स्थानीयकरण समर्थन के कोई अपडेट हैं?

Question

जितना अधिक मैं सी ++ लोकेल पहलुओं के साथ काम करता हूं, उतना ही मैं समझता हूं --- वे टूट जाते हैं।

• std::time_get - साथ std::time_put (के रूप में यह सी में strftime/strptime) सममित नहीं है और AM/PM अंकों के साथ समय की आसान पार्स अनुमति नहीं है।
• I discovered हाल ही में सरल संख्या स्वरूपण कुछ स्थानीय स्थानों (जैसे ru_RU.UTF-8) के तहत गैरकानूनी यूटीएफ -8 उत्पन्न कर सकता है।
• std::ctype यह मानना ​​बहुत सरल है कि प्रति-चरित्र आधार पर ऊपरी/निचले स्तर पर किया जा सकता है (केस रूपांतरण वर्णों की संख्या बदल सकता है और यह संदर्भ निर्भर है)।
• std::collate - संयोजन क्षमता (केस संवेदनशील या असंवेदनशील) का समर्थन नहीं करता है।
• टाइम स्वरूपण में वैश्विक टाइमज़ोन से अलग टाइमज़ोन निर्दिष्ट करने का कोई तरीका नहीं है।

और भी बहुत कुछ ...

• किसी को भी जानता है कि क्या कोई भी परिवर्तन C++ 0x में मानक पहलुओं में उम्मीद कर रहे हैं करता है?
• क्या ऐसे बदलावों का महत्व लाने का कोई तरीका है?

धन्यवाद।

संपादित करें: मामले में स्पष्टीकरण लिंक सुलभ नहीं है:

std::numpunct चार के रूप में हज़ार विभाजक परिभाषित करता है। तो जब यू + 2002 में विभाजक - विभिन्न प्रकार की जगह इसे यूटीएफ -8 में सिंगल चार के रूप में पुन: उत्पन्न नहीं किया जा सकता है लेकिन एकाधिक बाइट अनुक्रम के रूप में।

सी एपीआई struct lconv में हजारों विभाजक को स्ट्रिंग के रूप में परिभाषित करता है और इस समस्या से पीड़ित नहीं होता है। इसलिए, जब आप यूटीएफ -8 लोकेल के साथ ASCII के बाहर विभाजक के साथ संख्याओं को प्रारूपित करने का प्रयास करते हैं, तो अवैध यूटीएफ -8 का उत्पादन होता है। imbued ru_RU.UTF-8 स्थान के साथ ostream

EDIT2::

एसटीडी करने के लिए इस बग लिखने 1234 पुन: पेश करने के लिए मैं मानता चाहिए कि POSIX सी स्थानीयकरण एपीआई अधिक सहज काम करता है:

• वहाँ strftime का उल्टा होता है - - strptime (strftime std::time_put::put के समान होता है)
• ऊपर वर्णित बिंदु के कारण संख्या स्वरूपण के साथ कोई समस्या नहीं है।

हालांकि यह अभी भी perfecet होने के लिए है।

EDIT3: C++ 0x के बारे में नवीनतम नोटों के अनुसार मैं देख सकता हूँ कि std::time_get::get - strptime और std::time_put::put के विपरीत के समान है।

Answer 1

std::numpunct एक टेम्पलेट है। सभी विशेषज्ञता दशमलव सेपरेटर चरित्र को वापस करने का प्रयास करें।जाहिर है, किसी भी लोकेल में जहां यह एक विस्तृत चरित्र है, आपको std::numpunct<wchar_t> का उपयोग करना चाहिए, क्योंकि <char विशेषज्ञता ऐसा नहीं कर सकती है।

उस ने कहा, सी ++ 0x काफी अधिक किया गया है। हालांकि, यदि अच्छे सुधार जारी रहते हैं, तो सी ++ समिति सी ++ 1x शुरू करने की संभावना है। यदि आपके राष्ट्रीय आईएसओ सदस्य संगठन के माध्यम से पेश किया जाता है, तो आईएसओ सी ++ कमेटी आपकी मदद स्वीकार करने की संभावना है। मैं देखता हूं कि पावेल मिनेव ने एक दोष रिपोर्ट का सुझाव दिया था। यह तकनीकी रूप से संभव है, लेकिन आपके द्वारा वर्णित समस्याओं सामान्य डिजाइन सीमाओं में हैं। उस स्थिति में, कार्रवाई का सबसे विश्वसनीय तरीका इस के लिए बूस्ट लाइब्रेरी डिज़ाइन करना है, इसे बूस्ट समीक्षा पास करनी है, इसे मानक में शामिल करने के लिए सबमिट करें, और आईएसओ सी ++ मीटिंग्स में भाग लेने के लिए किसी भी मुद्दे से निपटने के लिए भाग लें।

Answer 2

मैं आपसे सहमत हूं, सी ++ में उचित i18n समर्थन की कमी है।

क्या कोई जानता है कि सी ++ 0x में मानक पहलुओं में कोई बदलाव अपेक्षित है या नहीं?

यह गेम में बहुत देर हो चुकी है, इसलिए शायद नहीं।

क्या ऐसे परिवर्तनों का महत्व लाने का कोई तरीका है?

मैं इस बारे में बहुत निराशावादी हूं।

सीधे पूछे जाने पर, स्ट्राउस्ट्रप ने दावा किया कि उसे वर्तमान स्थिति के साथ कोई समस्या नहीं दिख रही है। और बड़े सी ++ लोगों में से एक (पुस्तक लेखक और सभी) को यह भी एहसास नहीं हुआ कि अगर आप मानक पढ़ते हैं तो wchar_t एक बाइट हो सकता है।

और बूस्ट में कुछ धागे (जो भविष्य में दिशा को चलाने के लिए प्रतीत होता है) इस बात पर बहुत कम समझ दिखाता है कि यह कैसे काम करता है जो पूरी तरह से डरावना है।

सी ++ 0x मुश्किल से कुछ यूनिकोड चरित्र डेटा प्रकार, खेल में देर से और बहुत सारे संघर्ष के बाद जोड़ा गया। मैं बहुत जल्द के लिए अपनी सांस नहीं पकड़ रहा हूँ।

मुझे लगता है कि कुछ बेहतर देखने का एकमात्र मौका यह है कि अगर कोई वास्तव में i18n और C++ दुनिया में अच्छा/सम्मान करता है तो मानक के अगले संस्करण के साथ सीधे शामिल हो जाता है। कोई सुराग जो शायद हो सकता है :-(