की तुलना में बहुत बड़ी है। मेरे पास मानक डीबग/रिलीज बिल्ड विकल्प के साथ एक स्थिर लाइब्रेरी प्रोजेक्ट है। मैं यह जानकर चिंतित था कि डीबग के दौरान। लिब काफी बड़ा 22 एमबी है, रिलीज एक 100 एमबी है। और यह एक विशाल कोड-आधार नहीं है, लगभग 75 वर्ग और उनमें से कोई भी बहुत विशाल नहीं है।रिलीज एलआईबी डीबग
मेरे प्रश्न यह हैं कि यह सामान्य है, और क्या मुझे परवाह करना चाहिए?
आदर्श रूप से रिलीज lib को डीबग से छोटा होना चाहिए।
मुझे लगता है कि आप इस तरह के स्थिर MFC, ATL आदि जैसे अन्य libs जोड़ने जा सकता है ...
आप जारी करने और डीबग बिल्ड सेटिंग की जाँच करें।
एकाधिक समय फ़ाइल समावेशन से बचने के लिए #pragma once का उपयोग करें।
मैं आम तौर पर रिवर्स उम्मीद करेंगे ...
क्या यह संभव है कि एक ही रिलीज बनाता है में शामिल हो कोड पूर्वप्रक्रमक अंदर ब्लॉक शामिल के बड़े swaths देखते हैं कि?
टेम्पलेट कोड विशेष रूप से इस मामले में संदेह है।
अद्यतन
मुझे लगता है कि इस मुद्दे को सबसे अधिक संभावना को रिलीज़ मोड में स्थिर libs को जोड़ने के कारण होता है, और साझा डिबग मोड में libs ...
+1 karoberts
खाका कोड इनलाइन तरह से नष्ट हो जाता है डीबग बनाता में सिर्फ रिलीज की तरह है, ताकि यहां समस्या होने की संभावना नहीं है। –
सहमत, जब तक यह एक #if विज्ञप्ति या इसी तरह के मामले में है। –
मुझे ऐसा नहीं लगता है; एक रिलीज कंपाइलर/ऑप्टिमाइज़िंग टेम्पलेट कोड को किसी भी चीज़ के बगल में फोल्ड कर सकता है। यह एक बड़ा आकार अंतर है। –
नहीं , यह सामान्य नहीं है। होना तो इसका उलटा चाहिए। हाँ, आपको परवाह करना चाहिए।
मैं फिर से आकार को देखकर शुरू करूंगा, यह सुनिश्चित करने के लिए कि मैंने रिलीज को ट्रांसफर नहीं किया है और किसी भी तरह से डीबग आकार नहीं लगाया है।
फिर उन पुस्तकालयों को देखें जिन्हें आप रिलीज और डीबग के लिए जोड़ रहे हैं। क्या आपने डीबग लाइब्रेरी को गोपनीय रूप से जहाज से लिंक किया था, और डीबग करने के लिए लाइब्रेरी शिप किया था?
रिलीज और डीबग के लिए अपनी सेटिंग्स पर नज़र डालें। कुछ बहुत तेज चल रहा है।
क्या यह संभव है कि इस कोड की भारी मात्रा इनलाइन है, और डीबग संस्करण "इनलाइनिंग" नहीं है?
मैं यह देखने के लिए जांच करूंगा कि क्या आप रिलीज मोड में पुस्तकालयों को स्थिर रूप से जोड़ रहे हैं और गतिशील रूप से उन्हें डीबग मोड में लिंक कर रहे हैं। उदाहरण के लिए आप स्थिर रूप से C++ रनटाइम को लिंक कर सकते हैं।
+1: वहां गया। – Dathan
मान लिया जाये कि वह एक स्थिर पुस्तकालय परियोजना के बारे में पूछ रहा है, स्थिर पुस्तकालय कभी परियोजना में कुछ भी साथ जुड़ा हुआ नहीं है। स्थिर पुस्तकालयों का लिंक केवल लाइब्रेरी का उपयोग होने पर होता है। –
सही नील। यहां कोई लिंक नहीं है, केवल बाहरी # –
एक ऐसी चीज है जो इस तरह के आकार को समझा सकती है: रिलीज बिल्ड में एम्बेडेड डीबग प्रतीक (जैसा कि पीडीबी के रूप में बनाया गया है)। क्या आप वाकई अपने रिलीज बिल्ड के लिए जेबग प्रतीक उत्पन्न नहीं कर रहे हैं? (आप किस दृश्य सी ++ का उपयोग कर रहे हैं?)
2008 शामिल है। पीडीबी/डीबग जानकारी एक ऐसा क्षेत्र है जहां मैं बारीकी से देखने की योजना बना रहा हूं ... मैं आमतौर पर रिलीज और डीबग के लिए पीडीबी उत्पन्न करता हूं, लेकिन यह एक अलग फ़ाइल होना चाहिए। –
ठीक है। पीएचपी फाइलों का उपयोग करते समय अपराधी/Z7 और/या/yd हो सकता है। आप अपने कमांड लाइन पर उपयोग कर रहे सभी विकल्पों को प्रदान करना चाहेंगे। – Bahbar
मुझे एक ही समस्या थी। फिक्स बहुत आसान है। परियोजना संपत्ति/विन्यास गुण/जनरल/पूरे कार्यक्रम अनुकूलन उपयोग नहीं पूरे कार्यक्रम अनुकूलनउपयोग लिंक टाइम कोड जनरेशन के बजाय। मेरी स्थिर पुस्तकालय का आकार 5 एमबी से 1 तक घट गया।3MB
सुनिश्चित नहीं हैं कि क्यों, लेकिन यह मेरे लिए कारण था। यह वास्तव में एक मुद्दा नहीं होना चाहिए जबतक कि आप कहीं भी .lib फ़ाइलों को तैनात नहीं कर रहे हैं। यदि आप उन्हें अपने समाधान में स्थानीय रखते हैं, तो आपको ठीक होना चाहिए क्योंकि स्थिर lib का उपभोग करने वाली .exe या .dll फ़ाइल उस सामान को खत्म कर देगी जिसकी आवश्यकता नहीं है। मेरा प्रश्न: http://stackoverflow.com/questions/2472568/visual-c-9-0-2008-static-lib-boost-library-large-lib-file – CuppM
आप सही एक स्थिर पुस्तकालय परियोजना के बारे में पूछ रहे हैं? –
हाँ, क्षमा करें। स्पष्ट करने के लिए संपादित किया गया। –
मैं अब इस समस्या है। क्या आपको कारण मिला? –