को लागू परमाणु <T> :: दुकान

Question

मैं C++ 0x मसौदे से परमाणु पुस्तकालय को लागू करने का प्रयास कर रहा हूँ।

template <typename T> 
void atomic<T>::store(T pDesired, memory_order pOrder = memory_order_seq_cst); 

आवश्यकता राज्यों:

आदेश तर्क memory_order_consume नहीं किया जाएगा, memory_order_acquire, और न ही memory_order_acq_rel विशेष रूप से, मैं §29.6/8, दुकान विधि को लागू कर रहा हूँ।

मैं अगर यह इन में से एक है कि क्या करना है यकीन नहीं है। क्या मुझे कुछ भी नहीं करना चाहिए, अपवाद फेंकना चाहिए, अपरिभाषित व्यवहार करना चाहिए, या कुछ और करना चाहिए?

_{पी.एस .: "C++ 0x" एक मरी हुई मछलियों की तरह थोड़े लग रहा है: 3}

Answer 1

आप क्या चाहते हैं। कोई फर्क नहीं पड़ता कि।

जब आईएसओ राज्य है कि आप "कुछ करना नहीं होगा", यह कर अपरिभाषित व्यवहार है। यदि कोई उपयोगकर्ता ऐसा करता है, तो उन्होंने कार्यान्वयन के साथ अनुबंध का उल्लंघन किया है, और कार्यान्वयन इसे करने के अपने अधिकारों के भीतर है।

आप जो करने का फैसला करते हैं वह पूरी तरह से आपके ऊपर है। मैं जो कुछ भी आपके कार्यान्वयन को "बेहतर" बनाता हूं (आपकी आंखों में, तेज़ी से, अधिक पठनीय, कम से कम विस्मय के सिद्धांत के अधीन, और आगे) का चयन करता हूं।

मैं स्वयं, मैं पठनीयता के लिए जाना चाहते हैं गति एक करीबी दूसरा लेने के साथ (के बाद से मैं बात को बनाए रखने के लिए होता है)।

Answer 2

मैं नहीं बल्कि vaguey समझदार व्यवहार कुछ पागल कि मिल चाहते हैं।

ठीक है, आपकी लाइब्रेरी के संभावित उपभोक्ता के रूप में, यहां मैं यह चाहता हूं कि: यदि दस्तावेज उपयोग में कोई प्रदर्शन लागत नहीं है, तो देखें कि स्मृति_ऑर्डर मानों में से एक दूसरों के कार्यात्मक सुपरसैट प्रदान करता है, खासकर कुछ संबंधित एक कॉलर क्या असमर्थित तरीके से असमर्थित मोड की अपेक्षा कर सकता है (यदि कोई समझदार उम्मीद बन सकती है)। कॉलर को सबसे धीमा, सुरक्षित मोड मिल सकता है, लेकिन यह कुछ कार्यात्मक रूप से गलत से बेहतर है। आप अपने कोड के लिए सबकुछ सही करने पर क्लाइंट कोड की निर्भरता को कम करते हैं। इसके साथ समस्या - एक जोर/अपवाद की तुलना में - यह है कि यह एक परीक्षण वातावरण में अनजान हो सकता है, इसलिए एक प्रक्रिया चर को संदेशों को सीमित करने के लिए एक स्थिर चर का उपयोग करके std :: cerr को स्पष्टीकरण लिखने पर विचार करें। यह एक बहुत ही उपयोगी निदान है।

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

(वहाँ शायद मान जो अपने वर्तमान गणना में भी नहीं हैं के लिए एक समान मुद्दा है।)

Answer 3

मैं एक संकलन समय त्रुटि पसंद करते हैं। यदि ऐसा नहीं है, तो एक जोर() विफलता।

जोर अच्छा है क्योंकि यह रिलीज़ संस्करण से बाहर संकलित करता है तथा प्रदर्शन प्रभावित नहीं होगा है।

संकलित समय त्रुटियां और भी बेहतर हैं क्योंकि वे सॉफ़्टवेयर को बग पर यात्रा करने के इंतजार किए बिना अधिक तत्काल प्रतिक्रिया प्रदान करते हैं। संकलन समय त्रुटि जांच एक चीज है जिसे मैं पाइथन, रूबी, पर्ल कोड पर सी ++ कोड के बारे में पसंद करता हूं।