constexpr गणना की मात्रा पर व्यावहारिक सीमाएं

Question

एक प्रयोग के रूप में, मैंने संकलन समय पर std::array<uint32_t, 256> उत्पन्न करने के लिए कुछ कोड एक साथ रखा है। तालिका सामग्री स्वयं एक काफी सामान्य सीआरसी लुकअप टेबल हैं - केवल एक ही नई बात के बारे में constexpr फ़ंक्शंस का उपयोग प्रविष्टियों की गणना करने के लिए किया जाता है, जो सीधे स्रोत कोड में स्वत: जेनरेट की गई जादू तालिका डालने का विरोध करते हैं।

वैसे भी, इस अभ्यास ने मुझे उत्सुकता प्राप्त की: क्या संकलन की मात्रा पर कोई व्यावहारिक सीमाएं होंगी एक संकलक संकलन समय पर constexpr फ़ंक्शन या चर परिभाषा का मूल्यांकन करने के इच्छुक होगा? जैसे जीसीसी के -ftemplate-depth पैरामीटर जैसे टेम्पलेट मेटाप्रोग्रामिंग मूल्यांकन की मात्रा पर व्यावहारिक सीमाएं बनाते हैं। (मैं भी आश्चर्य है कि अगर एक पैरामीटर पैक की लंबाई पर व्यावहारिक सीमाओं हो सकता है - जो एक संकलन समय std::array एक std::integer_sequence मध्यवर्ती वस्तु का उपयोग कर बनाया के आकार को सीमित होगा।)

Answer 1

इस तरह के लिए

अनुशंसाएँ [implimits] ¶2 में पाया जा सकता:

(2.35)   —   Recursive constexpr function invocations [512]

(2.36)   —   Full-expressions evaluated within a core constant expression [1 048 576]

जीसीसी और बजना -fconstexpr-depth के माध्यम से समायोजन की अनुमति देते हैं (जो झंडा आप देख रहे थे है)।

लगातार अभिव्यक्ति मूल्यांकन व्यावहारिक रूप से एक सैंडबॉक्स में चलता है, क्योंकि undefined behavior must be preempted by the implementation। इसे ध्यान में रखते हुए, मुझे नहीं पता कि कार्यान्वयन मेजबान मशीन के पूरे संसाधनों का उपयोग क्यों नहीं कर सका। फिर फिर, मैं उन लेखन कार्यक्रमों की अनुशंसा नहीं करता जिनके संकलन के लिए स्मृति या अन्य अनुचित संसाधनों के गीगाबाइट की आवश्यकता होती है ...